23-02-RDS MySQL 内核 AliSQL 的演进-0521-new.pdf

《23-02-RDS MySQL 内核 AliSQL 的演进-0521-new.pdf》由会员分享，可在线阅读，更多相关《23-02-RDS MySQL 内核 AliSQL 的演进-0521-new.pdf（22页珍藏版）》请在三个皮匠报告上搜索。

1、RDS MySQL 内核 AliSQL 的演进-Advanced MySQL陈宗志(暴跳)目录AliSQL 在云存储上的适配和优化AliSQL 在 DDL 场景的优化AliSQL 在 Binlog 模块的优化AliSQL 和 DuckDB 在 HTAP 场景的解决方案目录AliSQL 在云存储上的适配和优化AliSQL 在 DDL 场景的优化AliSQL 在 Binlog 模块的优化AliSQL 和 DuckDB 在 HTAP 场景的解决方案数据库存算分离的问题存算分离架构的痛点(线上经验&系统实验)：采用云存储后出现慢SQL;I/O时延大、聚合带宽高；数据库网络带宽利用率低；刷脏时WAL写性

2、能入下降；数据库存算分离的挑战数据库存算分离的优化MySQL(ESSD)MySQL(Local)AliSQL(ESSD)Total Performance evaluation of MySQLPerformance BreakdownWAL acceleration breakdown目录AliSQL 在云存储上的适配和优化AliSQL 在 DDL 场景的优化AliSQL 在 Binlog 模块的优化AliSQL 和 DuckDB 在 HTAP 场景的解决方案DDL 发展过程DDL 是 MySQL 最高频的“变更”操作问题：“锁表”、性能抖动、执行时间长 不敢“变更”Copy DDLInpl

3、ace DDLInstant DDL原表临时表copy row原表原 B+tree新 B+tree原表modify metaB+tree阶段1（Prepare）阶段2（Execute）阶段3（Cleanup）buildX（不可读写）NO_WRITE（只读）SU（读写）MySQL DDL 发展过程：5.6 之前，Copy DDL5.6&5.7，Inplace DDL8.0 之后，Instant DDLDDL 执行过程：阶段一，元数据准备阶段二，数据拷贝阶段三，清理&生效DDL 优化目标：更快、更稳、更安全更快：秒级修改列（Modify&Change）IO&排序优化并行构建 B+tree（主键+二

4、级索引）更稳：Buffer Pool 管理优化，快速刷脏大文件异步删除，减少文件系统抖动AHI 清理优化，消除 AHI 导致的全局阻塞更安全：非阻塞 DDL，优化 DDL 过程 MDL 锁获取过程，避免 DDL 导致的业务雪崩Lag Free DDL，降低 DDL 导致的复制延迟性能对比01000200030004000500060001112131415161718191 101 111 121 131 141 151 161 171 181 191oltp_read_write+DDLDefaultFast DDLDDL 优化秒级修改列核心思路：元数据多版本Instant Drop+Ins

5、tant Add支持语法：ALTER TABLE?MODIFY COLUMN?,ALGORITHM=INSTANT;ALTER TABLE?CAHENG COLUMN?,ALGORITHM=INSTANT;mysql select*from t0;+-+-+-+|id|c1|c2|+-+-+-+|1|10|2025-05-19 13:52:09|+-+-+-+1 row in set(0.00 sec)mysql show create table t0G*1.row*Table:t0Create Table:CREATE TABLE t0(id int NOT NULL AUTO_INCRE

6、MENT,c1 int DEFAULT NULL,c2 datetime DEFAULT CURRENT_TIMESTAMP,PRIMARY KEY(id)ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci1 row in set(0.00 sec)mysql insert into t0(c1)values(2147483720);ERROR 1264(22003):Out of range value for column c1 at row 1mysql alter table

7、 t0 modify column c1 bigint,algorithm=instant;Query OK,0 rows affected(0.06 sec)Records:0 Duplicates:0 Warnings:0mysql insert into t0(c1)values(2147483720);Query OK,1 row affected(0.00 sec)mysql select*from t0;+-+-+-+|id|c1|c2|+-+-+-+|1|10|2025-05-19 13:52:09|2|2147483720|2025-05-19 13:54:06|+-+-+-+

8、2 rows in set(0.00 sec)mysql show create table t0G*1.row*Table:t0Create Table:CREATE TABLE t0(id int NOT NULL AUTO_INCREMENT,c1 bigint DEFAULT NULL,c2 datetime DEFAULT CURRENT_TIMESTAMP,PRIMARY KEY(id)ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci1 row in set(0.00

9、sec)目录AliSQL 在云存储上的适配和优化AliSQL 在 DDL 场景的优化AliSQL 在 Binlog 模块的优化AliSQL 和 DuckDB 在 HTAP 场景的解决方案大事务写 Binlog 优化Binlog Cache 临时文件转 Binlog 文件：避免因大事务写 Binlog 长时间阻塞实例的写操作消除实例抖动和预期外的 HA合入 MariaDB 10.8Binlog FilesBinlog CacheBinlog.000001CopyCopy 大 Binlog Cache 导致抖动Binlog FilesBinlog CacheBinlog.000001RenameR

10、ename Binlog Cache 高效稳定Binlog.000002Binlog.000003Binlog.00000210GB10GBBinlog 并行写模式从串行排队写 Binlog 变为并发写 Binlog，提示高负载下的性能：引入 Binlog Buffer 机制在 Group Commit 的基础上，提升 Group 间的并发能力BinlogEvents of Group1Events of Group2Events of Group3Group3Group4Group5BinlogEvents of Group1Events of Group2Events of Group3B

11、inlog BufferEvents of Group1Events of Group2Events of Group3Events of Group4Events of Group5Group3Group4Group5Writer ThreadGroup 间串行写入 BinlogGroup 间并行写入 Binlog BufferEvents of Group4Events of Group5Binlog 并行写模式高性能模式(1000,2)下，性能提升 40%22%35%51%33%30%33%29%32%8163264128256512102403000060000900001200001

12、50000180000oltp_update_non_index(SSD)Binlog On(0,2)Optimized BGC5%4%13%29%17%28%31%32%816326412825651210240100000200000300000400000500000600000oltp_write_only(SSD)Binlog On(0,2)Optimized BGCBinlog in Redo事务提交过程减少一次 IO，保证数据可靠性的同时提升性能：Binlog 写入 Redo Log减少一次 Sync 操作Prepare xidSync RedoWrite BinlogSync

13、BinlogCommit xidordered_commitRedo LogPrepare RecordBinlogBinlog EventsRedo LogPrepare RecordCommit RecordPrepare xidWrite Binlog to RedoSync RedoWrite BinlogCommit xidordered_commitRedo LogPrepare RecordBinlogBinlog EventsRedo LogPrepare RecordBinlog RecordBinlog RecordCommit RecordBinlog 并行写模式高可靠模

14、式(1,1)下，性能提升 40%136%136%144%81%42%34%38%39%030000600009000012000015000081632641282565121024oltp_update_non_index(SSD)Binlog In Redo OffBinlog in Redo On43%52%72%51%38%32%28%28%010000020000030000040000050000081632641282565121024oltp_write_only(SSD)Binlog In Redo OffBinlog in Redo On复制延迟优化Writeset 优化：

15、修复前缀索引 Bug(contribute)支持外键冲突检测支持 DDL 冲突检测Binlog 实时复制，彻底消除复制延迟：Binlog Realtime Replication大事务实时传输大事务实时回放DDL 实时回放User ThreadDump ThreadIO ThreadExtra Worker ThreadWorker ThreadRead ev in RL cacheApply evSet Gtid NextCommitFind BRR by GtidWait BRR ApplySkip Trx by GtidSendReceiveBRR EventsNormal Events

16、BRR EventNormal EventSignalExecutingCommitBinlog CacheBinlogBinlogBinlogRelay Log CacheBinlogBinlogRelay LogRename目录AliSQL 在云存储上的适配和优化AliSQL 在 DDL 场景的优化AliSQL 在 Binlog 模块的优化AliSQL 和 DuckDB 在 HTAP 场景的解决方案兼容 MySQL 的开源 HTAP 方案：集成 DuckDB 作为 MySQL 的存储引擎，数据使用 DuckDB 列式存储使用 DuckDB 计算引擎进行分析查询，具备向量化及并行查询能力高度

17、兼容 MySQL 语法，SQL函数、数据格式，返回值类型增加只读分析实例提供分析查询，与主库 Binlog 增量数据同步自动将实例中全部表转成 DuckDB引擎DuckDB 深度集成BinlogMySQL ConnectionMySQL SQL Parser&PrepareBinlogData DictionaryMySQLOptimizer&ExecutorInnoDB Buffer PoolInnoDB TablespaceDuckDB Buffer PoolDuckDB TablespaceDuckDBSQL ParserResultTranslatorDuckDB Optimizer&

18、ExecutorDMLAP DQLAP DQLMySQLInnoDBDuckDB高性能、低成本：TPCH sf100 测试，加速比 200+倍，磁盘空间占用 20%架构收敛：一个 RDS MySQL 实例内同时提供 TP 事务处理和 AP 查询能力SQL 高度兼容：字段类型 100%，支持事务原子性及隔离性，SQL 语法及函数兼容数据一致：查询结构一致，保证 Crash Recovery 一致性安全稳定：单独的只读分析副本，对主库运行没有影响同步链路稳定：复杂场景（如 DDL 操作），保持同步链路的连续性DuckDB 深度集成TPC-H 性能测试DuckDB 深度集成020040060080010001200140016001800200012345678910111213141516171819202122TPC-H sf100InnoDB引擎耗时DuckDB引擎耗时加速比