你遇到过 Mysql--index merge 死锁吗？

在我们的常规认知中，过滤条件肯定是推的越靠近底层越好，将尽可能多的过滤条件更贴近数据源，以使查询时能跳过无关的数据，在AnalyticDB MySQL中，由于存储计算分离架构，那么谓词下推就是把所有能推的谓词都推到存储节点上去做。比如下图，所有的过滤条件都推到存储节点上去做，这样减少了后续算子的计算量，也减少了中间网络传输的数据量。谓词下推带来了很多的好处，基本上所有数据库，都会把谓词下推作为他们重要的优化功能。

最近在折腾rust与数据库集成，选了Tidb Cloud Serverless Tier 作为数据源。Tidb 无疑是近五年来最优秀的国产开源分布式数据库，Tidb Cloud Serverless Tier作为pingcap旗下的云产品方便又经济。

Buffer Pool：缓冲池，简称 BP。其作用是用来缓存表数据与索引数据，减少磁盘 IO 操作，提升效率。

在数据库的运维工作中经常会遇到业务的改表需求，这可能是 DBA 比较头疼的需求，其中添加唯一索引可能又是最头疼的需求之一了。

MySQL 5.6 开始支持 Online DDL ，添加[唯一]索引虽然不需要重建表，也不阻塞 DML ，但是大表场景下还是不会直接使用 Alter Table 进行添加，而是使用第三方工具进行操作，比较常见的就属 pt-osc 和 gh-ost 了。本文就来总结梳理一下添加唯一索引的相关内容。

项目中需要使用 DAG 结构表示离线任务、数据源血缘关系及数据流向，采用 MySQL 来存储 DAG 数据结构并完成增删改查等常规功能。这里对 MySQL 存储、操作、遍历 DAG 图的方法进行记录。

由于传统的 mysql 数据库并不擅长海量数据的检索，当数据量到达一定规模时（估算单表两千万左右），查询和插入的耗时会明显增加。同样，当需要对这些数据进行模糊查询或是数据分析时，MySQL作为事务型关系数据库很难提供良好的性能支持。使用适合的数据库来实现模糊查询是解决这个问题的关键。

但是，切换数据库会迎来两个问题，一是已有的服务对现在的 MySQL 重度依赖，二是 MySQL 的事务能力和软件生态仍然不可替代，直接迁移数据库的成本过大。我们综合考虑了下，决定同时使用多个数据库的方案，不同的数据库应用于不同的使用场景。而在支持模糊查询功能的数据库中，elasticsearch 自然是首选的查询数据库。这样后续对业务需求的切换也会非常灵活。

那具体该如何实现呢？在又拍云以往的项目中，也有遇到相似的问题。之前采用的方法是在业务中编写代码，然后同步到 elasticsearch 中。具体是这样实施的：每个系统编写特定的代码，修改 MySQL 数据库后，再将更新的数据直接推送到需要同步的数据库中，或推送到队列由消费程序来写入到数据库中。

但这个方案有一些明显的缺点：

• 系统高耦合，侵入式代码，使得业务逻辑复杂度增加
• 方案不通用，每一套同步都需要额外定制，不仅增加业务处理时间，还会提升软件复复杂度
• 工作量和复杂度增加

在业务中编写同步方案，虽然在项目早期比较方便，但随着数据量和系统的发展壮大，往往最后会成为业务的大痛点。

InnoDB如何安全地崩溃恢复主要通过undo log机制来保证。事务的undo日志存放在undo段中，一个事务可能拥有多个undo段，事务prepare时会将所有undo段头部的TRX_UNDO_STATE字段修改为TRX_UNDO_PREPARED，这个操作完成后（完成的标准是修改undo段状态的所有redo日志都已落盘），事务所有的修改都已经持久化，即使程序崩溃也不会丢失（不考虑硬件损坏等特殊情况）。

作为国内领先的循环经济产业公司，随着转转业务的不断发展，基础服务设施已然到了“蜕壳”的阶段。

目前在用的IDC资源已趋于饱和，难以满足后续的发展需求。

同时，随着腾讯云提供的负载均衡技术迭代，需要将TGW（Tencent GateWay）替换为CLB（Cloud Load Balancer）。

经过运维同学近半年时间的筹划和建设，全新IDC和负载均衡技术（CLB）已完成升级建设并正式投产，MySQL、TiDB、Redis等公共基础服务需要有序进行迁移切换。对于MySQL迁移工作，面临集群数量多、操作影响大、操作要求高等一系列难题，需要充分调研现状并制定合理的方案，进一步降低对业务服务的感知。

业务系统查询，涉及多表关联查询，条件维度较大且有模糊匹配需求，索引无法覆盖，导致查询性能较低。

本文通过对InnoDB存储逻辑分析，了解到mysql中是怎样对数据进行存储的。并且对索引树的结构进行分析，帮助我们在工作中更加合理的使用索引。

分布式数据库OceanBase在携程的实践之路。

MVCC没有正式的标准，在不同的DBMS中MVCC的实现方式可能是不同的，也不是普遍使用的。本文讲解InnoDB中MVCC的实现机制。

MySQL 8.0 DDL 是一个复杂的过程，涉及比较多的模块，例如：MDL 锁，表定义缓存，行格式，Row Log，DDL Log，online 属性，表空间物理文件操作等。本文主要通过与5.7版本的对比讲述原子性相关的实现。

InnoDB 是 MySQL 默认的存储引擎，而提到InnoDB的内存，就绕不开Buffer Pool，该结构对性能的影响重大。但事实上InnoDB的内存消耗并不只有BP而已，其内部还有许多重要的结构（如AHI、Change Buffer、Log buffer等）也占据着不可忽视的内存空间。了解InnoDB的内存结构和使用特点对于MySQL运行期间的内存选型和使用有很大帮助。

在 InnoDB 引擎下，运行同一行内容在不同事务之间读写互不干扰，这是我们经常会碰到的业务场景，它也被认为是理所当然的。而这一特性的实现其实会比描述起来复杂得多。

MVCC 就是允许在特定隔离级别的 InnoDB 引擎下，对事务执行一致的读操作。避免了并发事务下对一般类型查询的锁竞争，也是一种增强并发事务读写能力的功能。

就像一位称职的摄像师，在你每个人生的高光点都会按下快门记录当下与之前的影像。

它本质上就是一个链表，每一行内容的版本都指向上一个版本，其中除了数据本身，还包含了事务可见性的信息在内，这些可见性信息用于判断哪个版本才能对当前的查询可见。