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

最近在工作中写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_id
    FROM position_view
    WHERE `date` > '2025-05-03'
      AND user_id = 1474358820237239206
) sub
INNER JOIN `position` p 
    ON p.id = sub.`position_id`;

 SQL-2

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

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

推荐选择

• 对于大表，推荐使用 第一条 SQL（子查询）
• 对于小表或中间结果较小的场景，推荐使用 第二条 SQL（直接连接）

案列二

  SELECT
        type,
        title,
        description,
        regionName,
        mobile
        FROM (
        SELECT
        p.`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 rn
        FROM
        position p
        INNER JOIN
        region r ON p.region_id = r.id
        
            p.`status`='ONLINE'
            AND p.`create_time` > #{date}
            
                AND p.`type` IN
                
                    #{type}
                
            
            
                AND p.`source` IN
                
                    #{source}
                
            
        
        ) AS sub
        WHERE
        sub.rn = 1
        LIMIT #{config.queryCount}

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

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

1. 时间范围大幅缩小

   • 原始查询：需处理整个 position 表的历史数据（可能上亿条）

   • 添加条件后：仅处理最近 #{date} 之后的数据（可能仅几万条）

   • 效果：扫描行数从指数级降至线性级

2. 窗口函数计算量骤减

   原始：需对全表手机号去重排序（海量排序+分组操作）

   • 添加条件后：仅需处理最近数据中的手机号

   • 效果：排序内存需求下降，避免磁盘临时文件

因为只需要查询1000条最新的数据，职位表每天都有新增1000条数据，所以只查询date天内的数据就可以，有效避免了慢SQL的问题。还有就是窗口函数很容易造成全表扫描，一定到关注性能

总结

在开发中，对于需要操作大表的SQL，特别要注意去正式环境运行一下SQL有没有SQL性能问题，上线之前规避问题，优化~~~