由 dawei 慢查询是MySQL性能问题最直观的信号。当一条SQL执行超过1秒，它可能已拖垮整个应用响应。但优化不该从EXPLAIN开始——先确认是否真为数据库瓶颈：通过应用埋点或APM工具验证慢的是SQL本身，而非网络延迟、连接池耗尽或业务逻辑阻塞。
定位真实慢SQL，依赖MySQL的慢查询日志（slow_query_log）与long_query_time参数。建议将阈值设为200ms，并开启log_queries_not_using_indexes，辅以pt-query-digest分析高频、高成本语句。注意关闭performance_schema对日志采集的干扰，避免误判。
索引失效是头号元凶。常见场景包括：在WHERE子句对字段做函数操作（如YEAR(create_time) = 2024）、隐式类型转换（字符串ID被当作数字比较）、或LIKE以通配符开头（’%abc’）。解决方式不是堆索引，而是重构查询逻辑或添加覆盖索引，让SELECT字段全部落在索引B+树叶子节点中。
AI设计草图，仅供参考
连表性能恶化往往源于驱动表选择错误。EXPLAIN结果中rows值过大时，检查关联字段是否都有高效索引；若小表关联大表却未走索引，手动用STRAIGHT_JOIN提示优化器；对于千万级分页，避免OFFSET，改用游标分页（WHERE id > last_id LIMIT 20）。
查询瘦身比索引更重要。删除SELECT ，只取必需字段；拆分复杂联合查询为多次简单查询，利用应用层聚合；对统计类慢SQL，考虑异步更新汇总表或引入Redis缓存结果。单次查询降低50%数据量，常比加索引提速更显著。
最后一步是稳定性保障。所有变更必须在预发环境压测验证QPS与响应时间波动；上线后观察5分钟内innodb_buffer_pool_read_requests与innodb_buffer_pool_reads比率，确保命中率＞99%；持续用Performance Schema监控statements_digest表，自动捕获新出现的“隐形慢SQL”。