吞吐量瓶颈在于innodb_buffer_pool_size、innodb_io_capacity、innodb_flush_log_at_trx_commit三者协同匹配硬件与写入模式；盲目调大缓冲池或关闭日志刷盘易致swap或数据丢失，引发吞吐暴跌。
直接结论：吞吐量瓶颈通常不在单个参数，而在 innodb_buffer_pool_size、innodb_io_capacity、innodb_flush_log_at_trx_commit 三者协同是否匹配硬件与业务写入模式。盲目调大缓冲池或关闭日志刷盘，反而可能因 swap 或数据丢失导致吞吐暴跌。
如何设置 innodb_buffer_pool_size 才不触发 swap
这个值设太高，OS 内存不足时会 swap，I/O 延迟跳到毫秒级，吞吐直接腰斩。
- 专用数据库服务器：设为物理内存的
70%～80%，但必须满足innodb_buffer_pool_size == innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances，否则 MySQL 启动时自动向上取整（比如你设12G，但 chunk 是128M、instances 是8，实际分配变成16G） - 查当前 chunk 大小：
SELECT @@innodb_buffer_pool_chunk_size;，默认是134217728（128MB） - 若服务器 32GB 内存，推荐组合：
innodb_buffer_pool_size = 24G，innodb_buffer_pool_instances = 16（24G ÷ 16 = 1.5G/实例，符合“每实例 1GB 左右”原则） - 上线后监控
SHOW ENGINE INNODB STATUS中的Buffer pool hit rate，持续低于99%就说明缓存不够用；同时用free -h确认系统剩余内存 > 2GB
为什么 innodb_io_capacity 必须按 SSD 实际 IOPS 设
这个参数不是“越大越好”，它控制后台预刷、合并、清除线程的活跃度。设错会导致 I/O 饱和或闲置。
- NVMe SSD（如 Intel P5800X）：设
innodb_io_capacity = 5000，innodb_io_capacity_max = 10000 - SATA SSD（如 Samsung 870 EVO）：设
innodb_io_capacity = 2000，innodb_io_capacity_max = 4000 - 务必关掉
innodb_flush_neighbors = 0（SSD 不需要顺序刷邻页） - 验证是否过载：查
performance_schema.file_summary_by_event_name中wait/io/file/innodb/innodb_data_file的平均延迟，超过10ms就说明 I/O 被压垮了
innodb_flush_log_at_trx_commit 怎么选才兼顾吞吐与安全
它决定日志何时落盘，是吞吐量最敏感的开关之一。金融和电商场景不能只看数字，要看事务粒度。
-
1：每次 COMMIT 都 fsync 到磁盘 → 安全，但吞吐受限于磁盘 fsync 延迟（NVMe 约 0.1ms，SATA 约 2ms） -
2：写入 OS cache + 每秒一次 fsync → 吞吐提升明显，崩溃最多丢 1 秒事务，生产环境最常用 -
0：每秒一次写入 OS cache → 吞吐最高，但 mysqld crash 会丢最多 1 秒日志，仅适合日志类、可重算场景 - 注意：
innodb_flush_log_at_trx_commit = 2时，必须确保sync_binlog = 1000或0，否则 binlog 和 redo 日志可能不一致，主从复制出问题
容易被忽略的并发与锁链路瓶颈
吞吐上不去，有时根本不是 I/O 或内存，而是锁等待或线程争用卡在了看不见的地方。
-
innodb_thread_concurrency = 0（默认）即可，InnoDB 自动适配 CPU 核心数；手动设非零值只在超高压（>10K QPS）且 CPU 利用率长期 100% 时才考虑 - 开启死锁记录：
innodb_print_all_deadlocks = ON，日志里出现高频*** (1) WAITING FOR THIS LOCK TO BE GRANTED:，说明索引设计或事务范围有问题 -
thread_cache_size推荐设为max_connections / 4（但不低于16），避免频繁创建销毁线程消耗 CPU - 真正压测前，先跑
SELECT COUNT(*) FROM sys.innodb_lock_waits;，非零就说明已有锁积压，别急着调参，先看慢查询和事务拆分
真正的吞吐瓶颈往往藏在 buffer pool 命中率、I/O 延迟、日志刷盘策略这三者的交叉点上——单独调一个参数就像拧松一颗螺丝去提速发动机，得先听清异响来自哪里。
