由 dawei 慢查询是MySQL性能问题最直观的信号。当一条SQL执行超过1秒，它可能已拖垮整个应用响应。但优化不该从EXPLAIN开始——先确认是否真为数据库瓶颈：通过应用埋点或APM工具验证慢的是SQL本身，而非网络延迟、连接池耗尽或业务逻辑阻塞。
定位慢查询必须依赖真实生产数据。启用slow_query_log并设置long_query_time=0.5（而非默认2秒），配合log_queries_not_using_indexes，确保捕获所有潜在隐患。用pt-query-digest分析日志，精准识别TOP 5消耗CPU和I/O的SQL，避免凭经验“猜”热点语句。
索引不是越多越好。对高频WHERE条件、JOIN字段和ORDER BY列构建复合索引，遵循最左前缀原则。例如SELECT FROM orders WHERE status=’paid’ AND created_at > ‘2024-01-01’ ORDER BY amount DESC，可建索引(status, created_at, amount)。删除长期未使用的冗余索引，减少写入开销与内存占用。
避免SELECT 和大范围OFFSET分页。用游标分页替代LIMIT 10000,20：记录上一页最大id，改写为WHERE id > 12345 ORDER BY id LIMIT 20。对统计类查询，预计算结果存入汇总表或使用Redis缓存，减少实时聚合压力。
AI做图，仅供参考
参数调优需结合硬件特性。innodb_buffer_pool_size设为物理内存的60%–75%，确保热数据常驻内存；关闭query_cache_type（MySQL 8.0已移除），避免全局锁争用；适当增大innodb_log_file_size以提升写吞吐。所有调整在测试环境压测验证，禁止盲目修改。
架构级突破常带来质变。读多写少场景引入Redis缓存热点数据；超大数据表按时间或ID哈希分表；核心订单库与日志库物理分离。单实例优化有上限，合理拆分+异步化+读写分离，才能让复杂查询稳定控制在毫秒级。