由 dawei 慢查询是MySQL性能瓶颈最直观的信号。定位问题第一步不是优化SQL，而是开启慢查询日志（slow_query_log），设置合理阈值（如long_query_time=1），配合pt-query-digest工具分析执行频率高、平均耗时长的TOP SQL。
索引失效是慢查主因。需警惕隐式类型转换（如WHERE user_id = ‘123’但字段为INT）、函数包裹字段（WHERE YEAR(create_time) = 2023）、以及LIKE以通配符开头（LIKE ‘%abc’）。通过EXPLAIN观察type是否为ALL或index，key是否为NULL，rows是否远超预期，精准识别缺失索引或冗余索引。
合理设计复合索引遵循最左前缀原则。例如高频查询为WHERE status=1 AND city=’Shanghai’ ORDER BY created_at DESC，可建联合索引(status, city, created_at)。避免为每个单列单独建索引，定期用sys.schema_unused_indexes视图清理无效索引，减少写入开销与内存占用。
AI绘图结果，仅供参考
查询本身可精简：禁用SELECT ，只取必要字段；分页改用游标方案（WHERE id > last_id LIMIT 20），避开OFFSET大偏移导致全表扫描；对聚合统计类慢查，考虑用物化视图思想——将结果预存至汇总表，定时刷新，换取毫秒级响应。
连接与配置不容忽视。调整wait_timeout、max_connections匹配业务峰值；innodb_buffer_pool_size建议设为物理内存的50%–75%，确保热数据常驻内存；监控InnoDB缓存命中率（Innodb_buffer_pool_read_requests / (Innodb_buffer_pool_read_requests + Innodb_buffer_pool_reads)），低于99%即需扩容缓冲池。
性能提升是持续过程。上线后用Performance Schema跟踪SQL运行时资源消耗，结合Redis缓存高频读结果，构建“数据库+缓存+索引+SQL重构”四层防线。一次慢查优化，可能从3.2秒降至47毫秒——这不是魔法，而是可观测、可验证、可复用的技术闭环。