常见慢SQL优化案例及解决方案（慢sql优化思路）

一、分页查询优化案例

问题现象：当使用LIMIT 1000000,10查询大量数据时，即使有索引也会非常慢

优化方案：

使用上一页的最大值作为查询条件：WHERE create_time > '2025-03-16 14:00:00' ORDER BY create_time LIMIT 10

为分页查询创建包含type、name和create_time字段的复合索引

二、隐式类型转换案例

问题现象：字段定义为varchar(20)，但查询时使用数字比较，导致索引失效

示例SQL：

sql

Copy Code

SELECT * FROM my_balance WHERE bpn = 14000000123 AND isverified IS NULL

优化方案：

确保查询变量与字段定义类型一致

修改查询为字符串比较：WHERE bpn = '14000000123'

三、GROUP BY性能问题案例

问题现象：GROUP BY查询耗时30多秒，即使添加索引效果不明显

优化方案：

尝试用DISTINCT替代GROUP BY

检查MySQL参数配置，某些客户端工具(如SQLyog)可能显示不准确的执行时间

添加ORDER BY NULL避免无用排序

四、夜间清算SQL优化案例

问题现象：批量清算时GROUP BY查询耗时10秒以上，导致清算延迟

示例SQL：

sql

Copy Code

SELECT fund_id,SUM(trade_amount) FROM trades

WHERE trade_date='2025-03-28' GROUP BY fund_id

优化方案：

创建联合索引：CREATE INDEX idx_trade_date_fund ON trades(trade_date,fund_id)

使用预计算表存储每日汇总结果

五、多表关联查询优化案例

问题现象：四表关联查询执行缓慢，实际执行时间达320毫秒

优化方案：

检查关联字段是否有合适索引

分析执行计划中的"Join Filter"和"Rows Removed by Join Filter"

考虑简化查询或拆分复杂SQL为多个简单查询

六、索引失效典型案例

问题场景：

在索引列上使用函数或运算

使用OR连接非索引列条件

违反最左前缀原则

优化建议：

确保WHERE条件遵循索引的最左前缀规则

避免在索引列上使用!=、<>等操作符

为常用查询条件创建合适的联合索引

七、全表扫描优化案例

问题现象：接口超时，发现SQL在UAT环境(数据量大)出现全表扫描

优化步骤：

通过执行计划确认全表扫描

检查表设计和数据量级

为查询条件添加合适索引

考虑对大表进行分区

关键优化原则总结

索引设计原则：

区分度高的列放在联合索引前面

覆盖常用查询条件和排序字段

SQL编写规范：

避免SELECT *，只查询必要字段

用JOIN替代低效子查询

注意隐式类型转换问题

监控与分析：

开启慢查询日志(long_query_time=1)

定期使用pt-query-digest分析慢SQL

通过EXPLAIN分析执行计划(type指标重点关注)