MySQL性能调优需结合业务负载分析瓶颈，优先优化SQL和索引，合理配置innodb_buffer_pool_size（50%–75%物理内存）、innodb_log_file_size（总大小1GB–4GB）、max_connections等参数，并根据安全与性能权衡innodb_flush_log_at_trx_commit值。
MySQL性能调优不是简单修改几个参数就能见效，关键在于理解参数作用、结合业务负载特征、观察实际效果并持续迭代。盲目调大缓冲区或连接数反而可能引发内存溢出或锁争用。
从慢查询和资源使用入手定位瓶颈
调优前必须明确“哪里慢、为什么慢”。先开启慢查询日志（slow_query_log=ON，long_query_time=1），配合pt-query-digest分析高频低效SQL；同时用SHOW GLOBAL STATUS和SHOW ENGINE INNODB STATUS查看线程等待、缓冲池命中率、I/O压力等指标。例如：若Innodb_buffer_pool_reads远高于Innodb_buffer_pool_read_requests，说明缓冲池过小导致频繁磁盘读取。
核心内存参数需按物理内存合理分配
- innodb_buffer_pool_size：通常设为物理内存的50%–75%（专用DB服务器），确保热数据常驻内存；避免超过系统可用内存，否则触发swap会严重拖慢性能。
- innodb_log_file_size：增大可减少checkpoint频率、提升写吞吐，但恢复时间变长；建议单个log文件不超2GB，总大小（innodb_log_files_in_group × innodb_log_file_size）控制在1GB–4GB之间，具体看写入峰值QPS。
- sort_buffer_size、join_buffer_size等线程级缓存不宜全局设高（如>4MB），应优先优化SQL走索引，而非靠增大临时缓存硬扛；必要时在会话级动态调整。
连接与并发相关参数要匹配实际负载
- max_connections：设为略高于应用最大连接池总和（如Spring Boot默认HikariCP是10，50个服务实例则预留600+），但需同步检查open_files_limit是否足够，避免“Too many open files”错误。
- innodb_thread_concurrency：MySQL 5.7+默认为0（不限制），一般无需调整；若CPU核数少、并发线程远超核数且出现明显mutex等待，可尝试设为2×CPU核数做粗粒度限制。
- wait_timeout和interactive_timeout：缩短空闲连接超时（如300秒），加快连接回收，避免连接堆积占用资源。
持久化与刷盘策略需权衡安全性与性能
对写密集型业务，innodb_flush_log_at_trx_commit是关键：
– 设为1（默认）：每次事务都刷盘，最安全但性能最低；
– 设为2：写入OS缓存即返回，崩溃可能丢失1秒内事务，多数场景推荐；
– 设为0：每秒刷一次，性能最高但风险最大，仅适用于日志类、可丢数据场景。
同时确保sync_binlog=1与之配合，保障主从一致性。
