innodb_flush_log_at_trx_commit=1并非必须开启，应依业务容忍度选择：支付类系统必须为1，日志/埋点等可设2，测试环境可设0；read_committed下见未提交数据是因会话复用未重置；长事务主要危害是undo log膨胀而非锁；ROW格式binlog体积大需压缩与清理。
innodb_flush_log_at_trx_commit=1 真的必须开吗？
多数人默认设为 1，认为这是 ACID 的铁律。但它直接导致每次事务都刷盘一次，高并发写入时磁盘 I/O 成瓶颈，响应时间陡增。实际是否需要，取决于业务对“掉电不丢数据”的真实容忍度。
常见错误现象：SHOW PROCESSLIST 中大量 updating 状态卡在日志刷写；sysstat 显示 %iowait 持续高于 30%；TPS 上不去但 CPU 很低。
- 支付、账务类系统：必须保持
1，哪怕牺牲 30% 吞吐 - 日志、埋点、消息队列中间表：可设为
2（每秒刷一次 log buffer 到 OS cache），掉电可能丢 1 秒数据，但响应时间常能提升 2–5 倍 - 测试/开发环境：设为
0可大幅提速，但仅限非生产
注意：2 不等于“不持久”，它仍调用 write()，只是不调 fsync()；而 0 连 write() 都跳过，全靠后台线程异步刷。
read_committed 隔离级别下，为什么还看到未提交变更？
这不是隔离级别失效，而是客户端没正确设置或连接复用导致的会话残留。MySQL 的事务隔离是会话级的，SET TRANSACTION ISOLATION LEVEL READ COMMITTED 只影响后续事务，不回滚当前已开启的事务。
使用场景：微服务中多个 HTTP 请求共用一个连接池连接（如 HikariCP 默认不重置会话变量），前一个请求开了事务但没提交/回滚，后一个请求读到了它的临时状态。
- 检查方式：执行
SELECT @@tx_isolation和SELECT TRX_ID, TRX_STATE FROM INFORMATION_SCHEMA.INNODB_TRX - 修复建议：在连接归还池前显式执行
ROLLBACK或SET autocommit = 1（推荐后者） - Spring Boot 用户注意：
spring.datasource.hikari.connection-init-sql=SET autocommit = 1能预防大部分问题
长事务拖垮性能：不是锁的问题，是 undo log 膨胀
很多人盯着 INFORMATION_SCHEMA.INNODB_LOCK_WAITS 查锁，却忽略真正拖慢系统的其实是 undo log 的持续增长——长事务阻止 purge 线程清理旧版本，导致 MVCC 快照变大、查询扫描行数暴增。
典型表现：SHOW ENGINE INNODB STATUS 中 HISTORY LIST 长度超过 10000；SELECT COUNT(*) FROM information_schema.INNODB_TRX 返回少量但 TRX_STARTED 时间早于 5 分钟的事务；慢查询里出现 Using filesort 或 Using temporary 频率异常升高。
- 监控关键指标：
innodb_history_list_length（通过SHOW STATUS LIKE 'Innodb_history_list_length'） - 自动终止方案：在应用层加事务超时（如 MyBatis 的
@Transactional(timeout = 30)），或用 MySQL 8.0+ 的max_execution_time限制单语句 - 避免在事务里做 HTTP 调用、文件读写、sleep() 等外部耗时操作
binlog_format=ROW 时，主从延迟和磁盘空间的隐性代价
ROW 格式虽保证复制一致性，但每条 UPDATE/DELETE 都记录完整行镜像，尤其大字段（text/blob）或批量操作时，binlog 体积可能比 STATEMENT 大 10 倍以上，既吃磁盘 IO，又拖慢 dump 线程传输速度。
容易踩的坑：误以为只要开了 GTID 就安全，结果某天发现 /var/lib/mysql/mysql-bin.000xxx 占满磁盘，或从库 Seconds_Behind_Master 持续 > 60s 且无法追上。
- 确认必要性：如果业务无函数、存储过程、非确定性语句（如
NOW(),UUID()），且所有表都有主键，ROW是稳妥选择；否则先评估MIXED - 压缩 binlog：MySQL 8.0+ 支持
binlog_transaction_compression = ON，实测对含 JSON/text 的写入可减小 40–70% 体积 - 定期清理：确保
binlog_expire_logs_seconds设为合理值（如 259200 = 3 天），而非依赖默认的expire_logs_days（已弃用）
事务一致性和响应时间从来不是非此即彼的选择题，而是每个参数背后具体的业务约束、硬件水位和运维能力的映射。调参前先看 innodb_status_output 和 slow_query_log 里最常卡住的那几行，比直接改 innodb_buffer_pool_size 有用得多。
