修改 innodb_buffer_pool_size
是最直接影响性能的配置
MySQL 启动后默认的
innodb_buffer_pool_size通常只有 128MB，哪怕你机器有 16GB 内存，InnoDB 也几乎全靠磁盘读取数据，QPS 上不去、慢查询频发基本都跟它有关。
建议值：生产环境设为物理内存的 50%–75%，但需预留至少 2GB 给 OS 和其他进程。例如 32GB 内存服务器可设为
24G（注意单位用
G而非
GB）。
实操注意点：
必须在my.cnf的
[mysqld]段落下配置，不能动态 SET（5.7+ 支持在线调整，但仍有约束，不推荐首次配置就用） 若设置过大（比如超 80%），可能触发系统 OOM killer 杀掉 mysqld 进程 重启生效，建议在低峰期操作并确认
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';返回值正确
关闭 innodb_flush_log_at_trx_commit=2
降低写入延迟（需权衡持久性）
默认值
1表示每次事务提交都刷盘，安全但慢；设为
2表示写入 OS cache 即返回，崩溃最多丢失 1 秒日志——对大多数业务可接受。
适用场景：日志类、埋点、实时报表等允许极小概率丢数据的写密集型服务。
不建议设为
0（每秒刷一次），除非你明确接受最多 1 秒全量丢失，且已做好 binlog + 备份兜底。
配套调整：
同步开启sync_binlog=1000（或
0），避免 binlog 刷盘成为瓶颈 确保
innodb_log_file_size≥ 256M（避免频繁 checkpoint） 务必验证主从复制是否仍稳定（
Seconds_Behind_Master无持续增长）
调大 max_connections
并配合应用连接池使用
默认
151连接数在微服务架构下极易打满，报错
Too many connections不是数据库扛不住，而是连接被耗尽。
合理值取决于应用连接池大小 × 实例数。例如：5 个服务实例，每个配 HikariCP
maximumPoolSize=20，那
max_connections至少设为
120（留余量）。
但光调大不够，必须检查：
是否有连接未正确 close（查SHOW PROCESSLIST;中大量
Sleep状态） 应用是否启用了连接泄漏检测（如 HikariCP 的
leakDetectionThreshold） 避免盲目设到 5000+，高连接数会显著增加线程调度和内存开销（每个连接约占用 256KB–1MB 内存）
禁用 DNS 反向解析避免连接卡顿
MySQL 默认会对每个新连接做反向 DNS 查询（
gethostbyaddr），如果客户端 IP 没配 PTR 记录，会卡住几秒才超时，表现就是应用偶发“连不上库”或“首次查询极慢”。
解决方法只有一行：
[mysqld] skip-name-resolve
副作用：所有
GRANT语句中必须用 IP 或
%，不能再用主机名（如
'app'@'web01.example.com'会失效）。
上线前务必检查现有账号权限定义，并批量改用 IP 段或通配符，否则重启后权限全部失效。
真正影响性能的从来不是冷门参数，而是这四个：缓存池大小、日志刷盘策略、连接上限、DNS 解析。改完它们，再看
SHOW ENGINE INNODB STATUS\G里的
Buffer pool hit rate和
Log sequence number增速，比任何监控图表都真实。
