最直接影响mysql性能的四个配置是innodb_buffer_pool_size、innodb_flush_log_at_trx_commit、max_connections和skip-name-resolve；需分别按内存比例设置缓冲池、权衡持久性调整日志刷盘、匹配应用连接池调大连接数、禁用dns解析避免连接卡顿。
修改 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 STATUSG 里的 Buffer pool hit rate 和 Log sequence number 增速，比任何监控图表都真实。