一、背景在预发环境中，由消息驱动最终触发执行事务来写库存，但是导致MySQL发生死锁，写库存失败。com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: rpc error: code = Aborted desc = Deadlock found when trying to get lock; try restart
为了标识一段数据，通常我们会为其指定一个唯一id，比如利用MySQL数据库中的自增主键。 但是当数据量非常大时，仅靠数据库的自增主键是远远不够的，并且对于分布式数据库只依赖MySQL的自增id无法满足全局唯一的需求。因此，产生了多种解决方案，如UUID，SnowFlake等。下文将介绍Vitess是如何解决这个问题的。
现象最近收到一个慢sql工单,慢sql大概是这样：“select xxx from tabel where type = 1”。咦，type字段明明有索引啊，为啥是慢sql呢？原因通过执行explain，发现实际上数据库执行了全表扫描，从而被系统判定为慢sql。这时有一定开发经验的同事会说：“字段区分度不够，这种字段作单独索引是没有意义的”。那么为什么会产生索引失效这种情况呢？索引失效都有哪些情况
一、实践背景介绍1、业务背景京东健康内容中台H2有一个目标就是需要替换两家CP内容（总体内容体量百万级），我们现在的逻辑是想按照PV热度优先高热去新生产和替换。替换后可以极大的节省cp内容引入的成本。第一步：这么多内容，我们的生产逻辑需要按照学科和索引归类和分配，进而批量生产，靠人工一篇篇补索引，效率会很低。希望借助算法的能力，如果现在还不是非常准确，也可以算法+人工修正，第二步：按索引归类好之后
大促备战，最大的隐患项之一就是慢SQL，对于服务平稳运行带来的破坏性最大，也是日常工作中经常带来整个应用抖动的最大隐患，在日常开发中如何避免出现慢SQL，出现了慢SQL应该按照什么思路去解决是我们必须要知道的。本文主要介绍对于慢SQL的排查、解决思路，通过一个个实际的例子深入分析总结，以便更快更准确的定位并解决问题。解决步骤step1、观察SQL出于一些历史原因有的SQL查询可能非常复杂，需要同时
一、治理背景数据库系统性能问题会对应用程序的性能和用户体验产生负面影响。慢查询可能导致应用程序响应变慢、请求堆积、系统负载增加等问题，甚至引发系统崩溃或不可用的情况。慢SQL治理是在数据库系统中针对执行缓慢的SQL查询进行优化和改进的一项重要工作。但原有的治理节奏，一般在大促备战期间，集中投入人力紧急治理，日常对慢SQL的关注度不高；即使研发团队想着手治理，实例下的SQL明细筛选繁琐，趋势不明，缺
UUIDUUID（通用唯一识别码）是由32个十六进制数组成的无序字符串，通过一定的算法计算出来。为了保证其唯一性，UUID规范定义了包括网卡MAC地址、时间戳、名字空间（Namespace）、随机或伪随机数、时序等元素，以及从这些元素生成UUID的算法。一般来说，算法可以保证任何地方产生的任意一个UUID都不会相同，但这个唯一性是有限的，只在特定的范围内才能得到保证。 UUID的一个非常明显的特点
在之前的文章中，我们介绍了弹性数据库连接失效的背景，并探讨了HikariCP、Druid连接池探活策略的相关内容。在本文中，我们将会继续探讨另一个线上常用的连接池——DBCP，并为您介绍如何在使用DBCP时实现最佳实践的弹性数据库连接池探活策略。
在上一篇文章中，我们介绍了弹性数据库连接失效的背景，并探讨了HikariCP连接池探活策略的相关内容。在本文中，我们将会继续探讨另一个线上常用的连接池——Druid，并为您介绍如何在使用Druid时实现最佳实践的弹性数据库连接池探活策略。
数据库连接建立是比较昂贵的操作（至少对于 OLTP），不仅要建立 TCP 连接外还需要进行连接鉴权操作，所以客户端通常会把数据库连接保存到连接池中进行复用。
本文简单介绍了读写分离架构，和出现主从延迟后，如果我们用的读写分离的架构，那么我们应该怎么处理这种情况，相信在日常我们的主从还是或多或少的存在延迟。本文介绍的几种方案，有些方案看上去十分不靠谱，有些方案做了一些妥协，但是都有实际的应用场景，需要我们根据自身的业务情况，合理选择对应的方案。
今天来说一个老生常谈的问题，来看一个实际案例：现有业务中往往都会通过缓存来提高查询效率，降低数据库的压力，尤其是在分布式高并发场景下，大量的请求直接访问Mysql很容易造成性能问题。有一天老板找到了你......老板：听说你会缓存？你：来看我操作。你设计了一个最常见的缓存方案，基于这种方案，开始对用户积分功能进行优化，但当你睡的正酣时，系统悄悄进行了下面操作：1、线程A根据业务会把用户id为1的积
今天针对Elasticsearch的Mapping类型进行修改，讨论几个可行的方案
KMS，Key Management Service，即密钥管理服务，在K8S集群中，以驱动和插件的形式启用对Secret，Configmap进行加密。以保护敏感数据
当使用了多个数据库来提供服务时，最为关键的点是如何让每一个数据库比较均匀的承担压力，而不至于其中的某些数据库压力过大，某些数据库没什么压力。这其中的关键点之一就是拆分键的设计。
MySQL服务端配置对使用方来说是不可更改的，需要联系DBA进行操作。这些配置操作对我们来说是一个黑盒，但是了解核心配置可以帮助我们快速定位数据库问题原因。
热key问题就是突然有几十万的请求去访问redis上的某个特定key，那么这样会造成流量过于集中，达到物理网卡上限，从而导致这台redis服务器直接宕机。
最近因需求改动新增了一些数据库表，但是在定义表结构时，具体列属性的选择有些不知其所以然，索引的添加也有遗漏和不规范的地方，所以我打算为创建一个高性能表的过程以实战的形式写一个专题，以此来学习和巩固这些知识
锁共有多种算法，在并发场景中都是被常常用到，想必大家都已炉火纯青般.....巴特！我们还有后浪同学们可能不熟悉，那我在这里聊下锁的用法和使用场景。
说到分布式事务，大家并不陌生。在实际工作中，用得比较多的还是柔性分布式事务，今天主要把在工作中运用到的几种柔性分布式事务的场景及实现方式做一个简单介绍，也可以看做是柔性分布式事务的一个演进过程。
典型的丢失更新问题，可以通过对数据库读操作加锁或者改变数据库的隔离级别为可串行化使事务串行执行的方式进行避免。下面我会将大家在讨论避免丢失更新问题时提出的方案进行介绍，并尽可能的用代码来表现它们。
本文从EXPLAIN分析SQL的执行计划开始，进行示例展示，并对输出结果进行解读，同时总结了EXPLAIN可产生额外的扩展信息以及EXPLAIN的估计查询性能，整篇文章基于MySQL 8.0编写，理论支持MySQL 5.0及更高版本。
不论是ACID事务还是基于流处理系统的分布式事务，它们都保证数据的完整性。因为违反及时性可能会令人困惑，不过这只是暂时的，但是如果违反完整性，那么它的结果可能是灾难性的。违反一致性，最终一致性；违反完整性，永无一致性，是最好的概括。
复制，即在不同的节点上保存相同的副本，提供数据冗余。如果一些节点不可用，剩余的节点仍然可以提供数据服务，这些节点可能部署在不同的地理位置，以此来改善系统性能
在mysql未支持json数据类型时，我们通常使用varchar、blob或text的数据类型存储json字符串，对mysql来说，用户插入的数据只是序列化后的一个普通的字符串，不会对JSON文档本身的语法合法性做检查，文档的合法性需要用户自己保证。在使用时需要先将整个json对象从数据库读取出来，在内存中完成解析及相应的计算处理，这种方式增加了数据库的网络开销并降低处理效率。
有很多的服务器选项会影响这MySQL服务器的性能，比如内存中临时表的大小、排序缓冲区等。有些针对特定存储引擎（如InnoDB）的选项，也会对查询优化很有用。
魔笛活动平台要记录每个活动的用户行为数据，帮助客服、运营、产品、研发等快速处理客诉、解决线上问题并进行相关数据分析和报警。可以预见到需要存储和分析海量数据，预估至少几十亿甚至上百亿的数据量，所以需要选择一款能存储海量数据的数据库。由于是通过接收MQ存储或者API方式存储，所以对实时写入性能也有一定要求。同时可能后续还需要一些实时数据分析等
本文介绍了分库分表的概念及优势,以及sharding-jdbc分库分表中间件,探究了sharding-jdbc的路由规则的执行流程
本文主要从TiDB的各类组件为起点，了解它的基础架构，并重点分析它在存储架构方面的设计，探究其如何组织数据，Table中的每行记录是如何在内存和磁盘中进行存储的。
InnoDB存储引擎最早由Innobase Oy公司开发（属第三方存储引擎）。从MySQL 5.5版本开始作为表的默认存储引擎。该存储引擎是第一个完整支持ACID事务的MySQL存储引擎，特点是行锁设计、支持MVCC、支持外键、提供一致性非锁定读，非常适合OLTP场景的应用使用。目前也是应用最广泛的存储引擎。
Copyright © 2005-2023 51CTO.COM 版权所有 京ICP证060544号
