三个指标的定义 在数据库性能评估中，经常会遇到 tpmC、tpm、tps 这三个指标，它们的含义如下： 指标 全称 含义 tpmC Transactions Per Minute (TPC-C) 每分钟处理的新订单事务数（TPC-C 基准） tpm Transactions Per Minute 每分钟处理的总事务数 tps Transactions Per Second 每秒处理的总事务数 注意区别：tpmC 只统计新订单，tpm 和 tps 统计所有类型的事务。 TPC-C 基准测试的事务模型 tpmC 来自 TPC-C 基准测试。TPC-C 模拟的是一个完整的订单处理系统，包含 5 种事务类型： 事务类型 占比 New Order（新订单） 45% Payment（支付） 43% Order Status（订单查询） 4% Delivery（发货） 4% Stock Level（库存查询） 4% tpmC 只统计其中的 New Order 事务，但系统实际上同时在处理其他 4 种事务。这就是换算公式中 0.45 这个系数的来源。 换算公式 1 tpmC = (1 / 0.45) / 60 ≈ 0.037 tps 逐步推导 假设系统性能为 1 tpmC，即每分钟处理 1 笔新订单： ...

一、如何评估并行复制能力是否需要调整？ 1.1 核心思路 MySQL 并行复制（MTS，Multi-Threaded Slave）的并行粒度由 last_committed 决定： last_committed 相同的事务，可以并行回放 sequence_number 是事务的全局递增序号 1.2 解析 binlog 查看并行度 1 2 # 解析 binlog，查看 last_committed 和 sequence_number mysqlbinlog --no-defaults -v /var/lib/mysql/binlog.000052 | grep -E "last_committed|sequence_number" | head -40 输出示例： #250101 10:00:01 server id 1 end_log_pos 256 GTID last_committed=10 sequence_number=11 #250101 10:00:01 server id 1 end_log_pos 512 GTID last_committed=10 sequence_number=12 #250101 10:00:01 server id 1 end_log_pos 768 GTID last_committed=10 sequence_number=13 #250101 10:00:01 server id 1 end_log_pos 1024 GTID last_committed=10 sequence_number=14 上面 4 个事务 last_committed 都是 10，说明这 4 个事务可以并行回放。 ...

前言 relay_log_recovery=ON 是 MySQL 主从复制中常见的安全配置，官方文档描述它的作用是：从库重启时，丢弃未执行的 relay log，从主库重新拉取。听起来很安全，但在特定条件下，它不仅救不了你，反而会导致 数据静默丢失 — 复制显示正常，实际上数据已经少了。 本文通过一个完整的实验，从环境确认、故障触发、原因分析到最终修复，逐步展示这个陷阱的全貌。 一、实验环境 角色 实例 服务器 主库 3308 120.48.119.118 从库 3309 101.34.248.57 MySQL 版本：8.0.35，GTID 模式，半同步复制。 从库关键参数 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 mysql> SHOW VARIABLES LIKE 'relay_log_recovery'; +--------------------+-------+ | Variable_name | Value | +--------------------+-------+ | relay_log_recovery | ON | +--------------------+-------+ mysql> SHOW VARIABLES LIKE 'relay_log_info_repository'; +--------------------------+-------+ | Variable_name | Value | +--------------------------+-------+ | relay_log_info_repository| TABLE | +--------------------------+-------+ mysql> SHOW VARIABLES LIKE 'slave_parallel_workers'; +-----------------------+-------+ | Variable_name | Value | +-----------------------+-------+ | slave_parallel_workers| 4 | +-----------------------+-------+ -- ↑ 多线程复制，这是出问题的关键！ mysql> SHOW VARIABLES LIKE 'slave_parallel_type'; +--------------------+---------------+ | Variable_name | Value | +--------------------+---------------+ | slave_parallel_type| LOGICAL_CLOCK | +--------------------+---------------+ mysql> SHOW VARIABLES LIKE 'gtid_mode'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | gtid_mode | ON | +---------------+-------+ 配置总结：GTID + AUTO_POSITION + relay_log_recovery + MTS(4 worker) ...

MySQL 内部两阶段提交（2PC）深度解析 一、背景与问题起源 MySQL 的存储架构分为两层： Server 层：负责 SQL 解析、优化、执行，以及 binlog 的写入 引擎层（InnoDB）：负责数据的实际存储，以及 redo log 的写入 这两层各自维护一套日志体系，当一个事务提交时，需要同时保证两套日志的一致性。若没有协调机制，极易造成数据不一致。 为什么两个日志会不一致？ 假设没有 2PC，先写 redo log，再写 binlog： [事务 T1 执行 UPDATE] → 写入 redo log（状态：commit） → MySQL 崩溃 💥 → binlog 未写入 恢复后： InnoDB 重放 redo log，T1 数据存在 从库通过 binlog 同步，T1 不存在 主从数据不一致！ 假设没有 2PC，先写 binlog，再写 redo log： [事务 T1 执行 UPDATE] → 写入 binlog → MySQL 崩溃 💥 → redo log 未写入 恢复后： InnoDB 没有 redo log，T1 回滚（数据不存在） 从库通过 binlog 同步，T1 被执行 主从数据不一致！ 正是因为这两种情况都会造成主从不一致，MySQL 引入了内部两阶段提交（Internal 2PC）。 ...