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，等于蒙眼修车——日志根本没录全。
