当前位置：首页 > news >正文

慢SQL调优(二)：大表查询

news 来源：原创 2025/6/6 22:13:49

最近在工作中写SQL出现几次慢SQL的BUG，总结下来归根到底就是因为大表的原因~这表有多大呢，执行 select COUNT(1) FROM `position` 是出不来结果滴，每天保底新增1000条数据，可想而知有多大了，所以多次踩坑了这张表。所以，这里总结一下，希望大家以后在开发中都可以注意一下，废话不多说直接开始~~

案例一

SQL-1

SELECT DISTINCT CONCAT_WS('_', p.type, p.drive_license) AS type_drive_license
FROM (SELECT DISTINCT position_idFROM position_viewWHERE `date` > '2025-05-03'AND user_id = 1474358820237239206
) sub
INNER JOIN `position` p ON p.id = sub.`position_id`;

SQL-2

SELECT DISTINCTCONCAT_WS('_', p.type, p.drive_license) AS type_drive_license
FROMposition_view pvINNER JOIN `position` p ON p.id = pv.`position_id`;
WHEREpv.`date` > '2025-05-03'AND pv.user_id = 1474358820237239206

这两个SQL最大的区别就是第一个SQL首先通过子查询查询筛选出满足条件的在查询，第二个直接通过内连接直接查询满足条件的数据。看似都可以实现功能，但是第二个就出现了慢SQL的问题，因为大表进行内连接，可能会出现全表扫描。所以采用第一种SQL

案列二

  SELECTtype,title,description,regionName,mobileFROM (SELECTp.`type`,p.`title`,p.`description`,r.`fullname` AS regionName,p.`mobile`,p.`create_time`,ROW_NUMBER() OVER (PARTITION BY p.`mobile` ORDER BY p.`create_time` DESC) AS rnFROMposition pINNER JOINregion r ON p.region_id = r.id<where>p.`status`='ONLINE'AND p.`create_time` > #{date}<if test="config.types != null and config.types.size() > 0">AND p.`type` IN<foreach collection="config.types" item="type" open="(" close=")" separator=",">#{type}</foreach></if><if test="config.sources != null and config.sources.size() > 0">AND p.`source` IN<foreach collection="config.sources" item="source" open="(" close=")" separator=",">#{source}</foreach></if></where>) AS subWHEREsub.rn = 1LIMIT #{config.queryCount}

性能提升原因分析（添加 `AND p.create_time > #{date}` 后）

核心原因：数据量级爆炸性减少

时间范围大幅缩小
- 原始查询：需处理整个 position 表的历史数据（可能上亿条）
- 添加条件后：仅处理最近 #{date} 之后的数据（可能仅几万条）
- 效果：扫描行数从指数级降至线性级
窗口函数计算量骤减

原始：需对全表手机号去重排序（海量排序+分组操作）
- 添加条件后：仅需处理最近数据中的手机号
- 效果：排序内存需求下降，避免磁盘临时文件