由 dawei 慢查询是MySQL性能问题最直观的信号。当一条SQL执行超过1秒，它可能已拖垮整个应用响应——但根源未必在SQL本身，而常藏于索引设计、执行计划、数据分布或配置失配中。
索引不是越多越好。高频WHERE条件字段、JOIN列、ORDER BY和GROUP BY涉及的列才值得建索引；联合索引需遵循最左前缀原则，例如(idx_user_status_time)能加速WHERE status=1 AND time > ‘2024-01-01’，却无法用于仅WHERE time > ‘2024-01-01’。用EXPLAIN验证索引是否真实命中，重点关注type（应为ref/const，避免ALL）、rows（越小越好）、Extra（警惕Using filesort或Using temporary）。
本图基于AI算法，仅供参考
避免“SELECT ”，只取必要字段；分页慎用OFFSET：LIMIT 10000,20会扫描前一万行。改用游标分页——记录上一页最大ID，查询WHERE id > 12345 ORDER BY id LIMIT 20，响应时间从秒级降至毫秒。
连接池与超时需精细控制。Spring Boot默认HikariCP连接池建议设置maximumPoolSize=20–50（依CPU核数与IO等待调整），connection-timeout=3000ms，validation-timeout=3000ms。同时关闭autoCommit=false场景下的长事务，避免锁表与Undo日志膨胀。
查询重写常比加索引更高效。例如将IN (SELECT user_id FROM log WHERE …) 改为JOIN，或把OR条件拆为UNION ALL（前提是结果集无重复且分支可独立走索引）。子查询若返回单值，优先改用JOIN或关联字段直接过滤。
配置调优需结合硬件。innodb_buffer_pool_size设为物理内存的60%–75%，确保热数据常驻内存；query_cache_type=OFF（MySQL 8.0已移除），避免缓存失效开销；slow_query_log=ON + long_query_time=0.1，配合pt-query-digest分析TOP耗时SQL。
监控是持续优化的基础。部署Percona Toolkit或使用Performance Schema，实时跟踪锁等待、I/O延迟、临时表创建频率。一个被忽略的tmp_table_size过小，会导致频繁磁盘临时表，让原本毫秒的聚合查询陡增至数秒。