SQL大表性能如何优化？真实案例解析与复杂查询思维强化

当业务系统中的订单表增长到数千万行时，原本在测试环境运行良好的统计SQL往往会在生产环境突然变慢。本文结合一个真实的报表查询案例，说明SQL大表性能优化的核心思路，并借此强化复杂查询的设计思维。

一、真实案例背景

某电商系统的订单表 order_record 约有 3200 万行，业务需要统计最近 30 天每个用户的下单总金额和下单次数。原始SQL如下：

SELECT user_id,
       COUNT(*) AS order_cnt,
       SUM(amount) AS total_amount
FROM order_record
WHERE create_time >= DATE_SUB(NOW(), INTERVAL 30 DAY)
  AND status LIKE '%paid%'
GROUP BY user_id;

该语句在高峰期执行超过 40 秒，严重影响报表导出。

二、性能瓶颈分析

1. 索引失效

对 status 字段使用 LIKE '%paid%' 会导致前缀模糊匹配，使该列上的普通索引无法生效，数据库只能进行全表扫描。

2. 过滤顺序不合理

create_time 虽然有索引，但优化器在存在 status 模糊条件时更容易选择全表扫描，因为估算成本偏高。

3. 复杂聚合缺乏覆盖索引

查询需要 user_id、amount、create_time、status 四列，若没有覆盖索引，分组和求和都要回表。

三、优化方案与改写

使用枚举代替模糊匹配

将 status 改为确定值，例如已支付为 2，SQL可改写为：

SELECT user_id,
       COUNT(*) AS order_cnt,
       SUM(amount) AS total_amount
FROM order_record
WHERE create_time >= DATE_SUB(NOW(), INTERVAL 30 DAY)
  AND status = 2
GROUP BY user_id;

建立联合覆盖索引

执行以下语句构建索引，使查询尽量在索引层完成：

CREATE INDEX idx_ct_status_uid_am
ON order_record (create_time, status, user_id, amount);

复杂查询思维：拆分与分批

如果用户量极大，可按照 user_id 哈希分桶，用程序并行汇总，避免单条SQL锁住大量数据：

# 按 user_id 取模分 8 批查询
for i in range(8):
    sql = (
        "SELECT user_id, COUNT(*), SUM(amount) "
        "FROM order_record "
        "WHERE create_time >= DATE_SUB(NOW(), INTERVAL 30 DAY) "
        "AND status = 2 AND user_id % 8 = %d "
        "GROUP BY user_id" % i
    )
    # 执行并合并结果

四、优化效果对比

五、总结

SQL大表性能优化并不只是加索引，更关键的是把复杂查询转化为数据库擅长执行的结构：避免索引失效的写法、利用覆盖索引减少回表、在业务层做合理拆分。通过本案例可以看到，将模糊状态改为枚举、设计联合索引以及分批处理，能显著降低响应时间，也训练了我们面对大表时的查询设计直觉。

SQL优化大表查询复杂查询修改时间：2026-07-29 03:45:19