配置陷阱：持久性、内存与锁等待

抄「最佳实践」把 innodb_buffer_pool_size 设为物理内存 80%，却忽略 每连接排序缓冲区 与 多个 buffer pool 实例的 NUMA 效应，OOM killer 先于慢查询到来。另一类陷阱是 innodb_flush_log_at_trx_commit=2 配 sync_binlog=1——以为「折中」，实际 RPO 语义仍由最弱环节决定。

本文每条配置对应 症状 → 查验 → 边界，依赖 第 3、4、12 篇。

一、配置决策树

flowchart TD
  Q[性能或稳定性问题?] --> MEM[内存: BP + 连接缓冲]
  Q --> DUR[持久性: flush + sync_binlog]
  Q --> LOCK[锁: lock_wait_timeout]
  MEM --> OOM[OOM / swap 风险]
  DUR --> RPO[崩溃丢数据窗口]
  LOCK --> TIMEOUT[应用 lock wait 错误]

二、innodb_buffer_pool_size

误区：越大越好。

查验：

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool%';
SHOW VARIABLES LIKE 'innodb_buffer_pool_instances';

边界：需为 OS、连接内存、其他进程留余量；多实例降低 latch 争用但单实例变小。NUMA 节点可配 innodb_buffer_pool_instances 与节点数对齐（需本地验证）。

二、持久性组合

见 第 12 篇。

三、innodb_lock_wait_timeout

与 死锁检测 独立：超时抛错，死锁自动回滚一方。过短误杀长更新；过长阻塞应用线程。

SHOW VARIABLES LIKE 'innodb_lock_wait_timeout';

四、max_connections 与内存

每连接可能分配 sort_buffer_size、join_buffer_size 等——连接数 × 缓冲区 可超过 BP。查验：

SHOW VARIABLES LIKE '%buffer_size';
SHOW STATUS LIKE 'Max_used_connections';

五、已废弃但仍见的参数

innodb_thread_concurrency（8.0 已移除效应）——升级后应删除旧配置。

六、配置查验清单

七、关键要点

1. BP 不是独占物理内存。
2. 持久性参数成对读。
3. 锁超时 ≠ 死锁检测。
4. 配置变更应 可回滚 + 有监控验证。

十、PG 对照

PG 单一 WAL 旋钮；MySQL 必须 成对 理解 redo 与 binlog（第 12 篇）。

上一篇：主从切换与数据恢复

系列完结：返回 系列索引

参考资料

源码（MySQL 8.0.36）

• storage/innobase/ — 引擎实现
• sql/binlog.cc, sql/handler.cc — Server 层交界

官方文档

• MySQL 8.0 Reference Manual, InnoDB / Replication / Backup

相关文章

• 系列索引
• PostgreSQL 内核系列