MySQL初始配置直接影响SQL性能，默认innodb_buffer_pool_size仅128MB左右，远低于服务器内存，导致频繁磁盘读、查询延迟高、锁等待加剧；应设为物理内存50%–75%或不低于数据文件总大小。
MySQL初始配置对SQL执行性能有直接影响
默认安装的MySQL（尤其是Windows一键安装包或Docker镜像）通常使用保守的内存配置，innodb_buffer_pool_size 可能仅设为128MB甚至更低。这意味着即使服务器有16GB内存，InnoDB也几乎无法缓存热数据，大量SQL会频繁触发磁盘随机读，SELECT 延迟飙升、UPDATE 事务锁等待加剧——这不是SQL写得差，是环境没调。
关键参数必须按实际负载重设
不改配置就上线，等于让MySQL“赤脚跑马拉松”。重点不是全量调优，而是盯住三个硬指标：
-
innodb_buffer_pool_size：应设为物理内存的50%–75%（专用DB服务器），至少不低于数据文件总大小；低于此值，Buffer Pool命中率长期SHOW ENGINE INNODB STATUS 中Buffer pool hit rate会持续报警 -
innodb_log_file_size：默认48MB太小，高并发写入易触发日志切换与Checkpoint阻塞；建议单个日志文件≥1GB（需停库修改，且要同步调整innodb_log_files_in_group） -
max_connections：默认151，但连接池未释放或长事务堆积时，Too many connections错误频发；应结合应用连接池最大值+20%冗余设置，而非盲目拉高
Docker或云数据库环境容易忽略底层限制
在Docker中运行MySQL，--memory 或 resources.limits.memory 若未显式限制，容器可能被OOM Killer干掉；但若限制过严（如只给2GB内存），而innodb_buffer_pool_size 设为1.5GB，系统缓存和MySQL线程栈就会争抢，反致性能抖动。云RDS看似省心，但其“最大连接数”“IOPS配额”“备份期间IO限速”等隐性约束，会让原本稳定的SQL在备份窗口突然超时——务必查清服务商文档里的mysql.rds_set_configuration 或控制台中的“性能限值”页。
慢查询不是代码问题，先看slow_query_log是否真开启
很多人以为开了slow_query_log = ON 就万事大吉，其实漏了两个致命开关：
-
long_query_time默认是10秒，业务里300ms的查询已明显卡顿，但不会记入慢日志；建议设为0.3（支持小数） -
log_output默认是FILE，但某些云环境或容器未挂载日志目录，日志实际没落地；更可靠的是设为TABLE，然后查mysql.slow_log表（需提前启用slow_query_log = ON且重启）
没确认这两项就分析慢SQL，等于蒙眼修车——日志根本没录全。
