mysql 5.7 吞吐瓶颈主因是默认 innodb_read_io_threads 和 innodb_write_io_threads 均为4，严重压制多核与高i/o设备能力；须设为8～16（≤物理核数×1.5），并确认 innodb_use_native_aio=on、innodb_buffer_pool_instances 匹配核数与缓冲池大小、open_files_limit 与系统 nofile 同步调高，四者协同方可释放真实性能。
MySQL 5.7 的 InnoDB 吞吐量瓶颈，90% 不在 SQL 或索引，而在默认参数对多核、高 I/O 设备的严重压制——调不对 innodb_read_io_threads 和 innodb_write_io_threads，24 核 CPU 也只跑出 4 核的 I/O 能力。
为什么 innodb_read_io_threads 和 innodb_write_io_threads 必须改
MySQL 5.7 默认两者都是 4，无论你接的是 NVMe 还是 RAID10，后台读写线程数就卡死在这 8 个（4+4）。结果就是：CPU 使用率只有 40%，Innodb_buffer_pool_wait_free 持续上涨，QPS 卡在瓶颈，SHOW ENGINE INNODB STATUS\G 里 “I/O thread” 段显示活跃线程长期 ≤6。
- 必须设为 8～16，上限不超过物理核数 × 1.5（例如 16 核物理 CPU，最大设到 24，但建议先试 16）
- Linux 下必须确认
innodb_use_native_aio = ON（默认开启，但要查；Windows 不支持 native AIO，设高无效） - 改完后执行
SHOW VARIABLES LIKE '%io_threads%'验证值已加载，再用SHOW ENGINE INNODB STATUS\G观察 “I/O thread” 实际活跃数是否接近配置值
innodb_buffer_pool_instances 设多少才不抢锁
缓冲池实例数不是越大越好，设错反而引发 mutex 争抢。常见错误是把 innodb_buffer_pool_size 扩大一倍，就把 innodb_buffer_pool_instances 也翻倍，完全忽略物理核数约束。
- 当
innodb_buffer_pool_size ≥ 8G，起点建议设为 16；若物理核数 ≤ 8，就别设超过 8 - 检查是否争抢：持续观察
SHOW STATUS LIKE 'Innodb_buffer_pool_wait_free'，>0 就说明实例太少或 buffer pool 太小 - 关键对齐规则：
innodb_buffer_pool_size必须是innodb_buffer_pool_chunk_size × innodb_buffer_pool_instances的整数倍（默认 chunk 是 128M）；例如设innodb_buffer_pool_size = 24g，就必须同步设innodb_buffer_pool_instances = 16（因为 24G ÷ 128M = 192，192 ÷ 16 = 12，整除）
组提交（Group Commit）真正生效的配置组合
组提交不是自动开的“加速器”，它只在特定参数组合下才合并 fsync()。两个参数都设为 1，组提交就彻底失效，所有事务串行刷盘。
- 有效组合只有：
sync_binlog = 1+innodb_flush_log_at_trx_commit = 2 -
innodb_flush_log_at_trx_commit = 1会强制每个事务刷 redo log，堵死 InnoDB 层打包空间 - 压测时盯紧
SHOW GLOBAL STATUS LIKE 'Binlog_group_commit_trigger_count'，值稳定增长才说明真在打包；如果Binlog_group_commit_trigger_lock_wait持续上升，说明事务卡在 MDL 锁或行锁，根本进不了 flush 队列——这时调 delay 没用，得查慢日志里Lock_time高但Query_time短的语句
系统级限制不跟上，MySQL 再怎么调都是假优化
MySQL 5.7 高并发下文件句柄消耗极快，open_files_limit 和 Linux 的 nofile 不同步，连接一多就报 Too many open files，所有线程卡死在 open() 环节。
-
open_files_limit至少设为max_connections × 2（每个连接常打开 1～2 张表） - Linux 端必须同步改
/etc/security/limits.conf：mysql soft nofile 65535mysql hard nofile 65535
然后执行systemctl daemon-reload - 别漏掉
vm.swappiness = 1：设为 0 可能在内存突增时触发 OOM killer 杀 MySQL；设为 1 几乎不换出，又保留底线
最易被忽略的点是：所有这些参数必须协同生效。单独调高 innodb_read_io_threads 但 innodb_buffer_pool_instances 太小，高并发下内部锁竞争反而升高；innodb_flush_log_at_trx_commit = 2 开了组提交，但 open_files_limit 卡在默认 5000，连接数一过 2000 就开始排队等文件句柄——吞吐量还是上不去。
