At Meta, we run one of the largest deployments of MySQL in the world. The deployment powers the social graph along with many other services, like Messaging, Ads, and Feed. Over the last few years, we have implemented MySQL Raft, a Raft consensus engine that was integrated with MySQL to build a replicated state machine. We have migrated a large portion of our deployment to MySQL Raft and plan to fully replace the current MySQL semisynchronous databases with it. The project has delivered significant benefits to the MySQL deployment at Meta, including higher reliability, provable safety, significant improvements in failover time, and operational simplicity — all with equal or comparable write performance.

本文介绍了MySQL慢查询日志的配置方式和日志内容格式。慢查询日志参数可通过写入MySQL配置文件或在MySQL Server中临时开启来进行配置。日志中记录了每条慢SQL的执行时刻、执行用户、执行时间、获取锁时间、发送给Client端的行数和扫描的行数等信息。开发者可以根据日志内容进行性能优化。

MySQL使用分区剪枝来确定哪些分区符合查询条件，根据不同的分区类型进行判断。使用SEL_TREE描述区间范围进行剪枝，每个SEL_ARG包含一个或多个分区键。SEL_TREE可以分为三种情况，其中第三种情况是多个index merge tree，可以描述成merge_tree1 AND merge_tree2 ... AND merge_treeN，每个merge tree类似于第二种情况。在find_used_partitions中，根据分区类型和剪枝条件是否为一个等值查询进行剪枝，剪枝的结果取并集。如果无法只创建一个SEL_ARG，则会创建一个index_merge tree。

MySQL Replication（主从复制）是指数据变化可以从一个MySQL Server被复制到另一个或多个MySQL Server上，通过复制的功能，可以在单点服务的基础上扩充数据库的高可用性、可扩展性等。

你遇到过 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在携程的实践之路。