---
tags: [MySQL, 查询优化, 重写, 性能调优]
create time: 2026-05-16 00:00
---

# 查询改写技巧

## 概述

同样的业务需求可能有多种 SQL 写法，性能差异可达几十倍。本章总结常用的 SQL 改写模式，帮助你将「能跑的 SQL」变成「跑得快的 SQL」。

## 1. OR → UNION ALL

```sql
-- ❌ 差：两个列各自独立，OR 会导致两边都无法走索引
SELECT * FROM users
WHERE email = 'alice@example.com' OR phone = '13800138000';
-- EXPLAIN: type=ALL, Rows=1000000 → 全表扫描

-- ✅ 好：拆成两次索引查询 + UNION ALL
SELECT * FROM users WHERE email = 'alice@example.com'
UNION ALL
SELECT * FROM users WHERE phone = '13800138000';
-- 两次独立的 ref 查询，各走一个索引
```

> [!TIP] 什么时候不该改？
> - 如果 OR 两边的列在**同一个联合索引**中，原写法可以利用最左前缀
> - 如果结果集非常小（几行），优化器可能自行选择最优方案

## 2. JOIN → EXISTS

```sql
-- ❌ 存在重复行的风险
SELECT DISTINCT u.* FROM users u
JOIN orders o ON u.id = o.user_id
WHERE o.amount > 1000;
-- 一个用户有多张大额订单时会重复，DISTINCT 又带来排序开销

-- ✅ 改用 EXISTS（找到第一条就停止）
SELECT u.* FROM users u
WHERE EXISTS (
    SELECT 1 FROM orders o
    WHERE o.user_id = u.id AND o.amount > 1000
);
```

> [!NOTE] MySQL Optimizer 的智能
> 现代 MySQL（8.0+）的优化器已经足够聪明，经常能把 JOIN 和 EXISTS 转换为相同的执行计划。但显式使用 EXISTS 语义更清晰，且在某些复杂场景下确实能引导优化器选更好的路径。

## 3. 子查询 → JOIN

```sql
-- ❌ 标量子查询可能导致 N+1
SELECT u.username,
       (SELECT SUM(amount) FROM orders WHERE user_id = u.id) AS total_spent
FROM users u;

-- ✅ 换成 GROUP BY + JOIN
SELECT u.username, COALESCE(SUB.total_spent, 0) AS total_spent
FROM users u
LEFT JOIN (
    SELECT user_id, SUM(amount) AS total_spent
    FROM orders GROUP BY user_id
) SUB ON u.id = SUB.user_id;
```

```mermaid
flowchart TD
    subgraph "子查询方案"
        A1["10万用户"] --> A2["每个用户查一次 SUM()"]
        A2 --> A3["总计 10万次扫描 orders 表"]
    end

    subgraph "JOIN 方案"
        B1["1次 GROUP BY orders"] --> B2["1000个汇总结果"]
        B2 --> B3["10万次 LEFT JOIN 1000行<br/>成本极低"]
    end
    
    style A3 fill:#EE5A24,color:#fff
    style B3 fill:#00D866,color:#fff
```

## 4. 避免函数包裹索引列

```sql
-- ❌ YEAR() / DATE() 包裹索引列 → 索引失效
SELECT * FROM orders
WHERE YEAR(created_at) = 2026 AND MONTH(created_at) = 5;
-- EXPLAIN: type=ALL, Rows=1000000

-- ✅ 改用范围查询 → 走索引
SELECT * FROM orders
WHERE created_at >= '2026-05-01'
  AND created_at < '2026-06-01';
```

```mermaid
flowchart LR
    Func["WHERE YEAR(col) = 2026"] --> F1["每一行都要计算 YEAR()"]
    F1 --> F2["无法利用 B+ Tree 二分查找"]
    F2 --> F3["全表扫描 ALL"]
    
    Range["WHERE col >= '2026-01-01' AND col < '2027-01-01'"] --> R1["直接在 B+ Tree 中定位范围"]
    R1 --> R2["索引范围扫描 range"]
    R2 --> R3["O(log N) 复杂度"]
    
    style F3 fill:#EE5A24,color:#fff
    style R3 fill:#00D866,color:#fff
```

## 5. 分页优化：延迟关联 + 游标分页

### 5.1 延迟关联（Deferred Join）

```sql
-- ❌ 深分页灾难
SELECT * FROM articles
WHERE status = 1
ORDER BY created_at DESC
LIMIT 999990, 10;
-- 扫描聚簇索引跳过 999990 行，每行都拉完整数据

-- ✅ 延迟关联：子查询只扫主键，外层精准 JOIN
SELECT a.* FROM articles a
INNER JOIN (
    SELECT id FROM articles
    WHERE status = 1
    ORDER BY created_at DESC
    LIMIT 999990, 10
) tmp ON a.id = tmp.id;
-- 子查询只扫主键（极紧凑），外层精准 JOIN 10 条
```

```mermaid
flowchart LR
    subgraph "传统方式"
        A1["扫描 999990 行完整数据"] --> A2["丢弃 999990 行"]
        A2 --> A3["返回 10 行"]
    end

    subgraph "延迟关联"
        B1["子查询扫 999990 行<br/>仅提取主键(8 bytes)"] --> B2["精准 JOIN 10 个主键"]
        B2 --> B3["返回 10 行完整数据"]
    end

    A3 ---|"I/O 减少 90%+"| B3

    style A1 fill:#EE5A24,color:#fff
    style B1 fill:#00B6BC,color:#fff
    style B3 fill:#00D866,color:#fff
```

### 5.2 游标分页（Keyset Pagination）

延迟关联能缓解，但**不是根治方案**。当 offset 极大时仍要遍历大量行。更优解是**基于上一页最后一个 ID 定位下一页起点**。

```sql
-- ❌ offset 越大越慢，且并发翻页可能丢数据
SELECT * FROM articles ORDER BY id DESC LIMIT 100000, 10;

-- ✅ 游标分页：记住上一页最后一条的 id
SELECT * FROM articles
WHERE id < 999980  -- 上一页最后一条的 id
ORDER BY id DESC
LIMIT 10;
```

> [!TIP] Go 应用层写法
> ```go
> // 第一页：无游标
> db.Order("id DESC").Limit(10).Find(&articles)
>
> // 后续页：用最后一条的 ID 做游标
> lastID := articles[len(articles)-1].ID
> db.Where("id < ?", lastID).Order("id DESC").Limit(10).Find(&articles)
> ```

> [!WARNING] 注意事项
> - 要求排序列有**唯一索引**（如自增主键）。如果排序字段不唯一（如 `created_at`），需加辅助条件：`WHERE (created_at, id) < (?, ?)` 利用联合索引最左前缀。
> - 前端无法直接跳到第 N 页——这是合理的 UX 约束。现代平台（Twitter、Instagram）均采用「加载更多」而非页码导航。

## 6. 避免 SELECT * 陷阱

```sql
-- ❌ 拉取不需要的列：浪费网络带宽 + 无法使用 Covering Index
SELECT * FROM orders WHERE user_id = 42;

-- ✅ 只查需要的列 → 可能变成 Covering Index（完全不碰数据行）
SELECT id, amount, status FROM orders WHERE user_id = 42;
```

> [!TIP] 为什么指定列更快？
> - InnoDB 聚簇索引叶子节点存整行数据。如果查询的列都在辅助索引中，MySQL 直接从辅助索引取数（**Using index**），不需要回表。
> - 网络传输的数据量也显著降低——去掉 TEXT/BLOB 列可能从 MB 级降到 KB 级。

## 7. LIKE 与全文搜索

```sql
-- ❌ 左模糊匹配导致全表扫描
SELECT * FROM articles WHERE title LIKE '%MySQL%';
-- EXPLAIN: type=ALL

-- ✅ 前缀模糊走索引
SELECT * FROM articles WHERE title LIKE 'MySQL%';

-- ✅ 大文本搜索用全文索引（FULLTEXT）
ALTER TABLE articles ADD FULLTEXT INDEX ft_title (title);
SELECT * FROM articles
WHERE MATCH(title) AGAINST('MySQL' IN NATURAL LANGUAGE MODE);
```

> [!NOTE] LIKE vs FULLTEXT
> - `LIKE 'prefix%'` 走 B+ Tree 范围扫描，适合精确前缀匹配
> - `FULLTEXT` 支持分词、相关性排序（ relevance ranking），适合搜索引擎场景
> - MySQL 的 FULLTEXT 对中文效果有限（空格分隔分词器不适用于中文），中文场景建议对接 Elasticsearch

## 8. 近似聚合：SUM(COL) vs SUM(1)

> [!QUESTION] 下面两行 SQL 有什么区别？
> ```sql
> -- Q1: 这两行结果一样吗？哪个更快？
> SELECT SUM(status = 1) FROM orders;
> SELECT SUM(CASE WHEN status = 1 THEN 1 ELSE 0 END) FROM orders;
> ```
> **答案**: 结果相同，但写法 1 更简洁且执行效率略高。MySQL 将布尔表达式视为 0/1 整数，`SUM(TRUE)` 等价于计数。

```sql
-- ✅ 简洁写法：布尔表达式直接参与算术
SELECT
    SUM(status = 'pending')   AS pending,
    SUM(status = 'shipped')   AS shipped,
    SUM(status = 'completed') AS completed
FROM orders;

-- 等价于多 CASE WHEN 写法，但更短、可读性更好
```

> [!WARNING] NULL 处理差异
> - `SUM(col = val)` 在条件不满足时返回 0，在列为 NULL 时也返回 NULL（即 0+NULL=NULL）
> - 如果需要对 NULL 安全计数，用 `SUM(CASE WHEN col = val THEN 1 ELSE 0 END)` 或加 `COALESCE`

## 9. COUNT 优化策略

### 9.1 利用索引覆盖计数

```sql
-- ❌ 无索引：全表扫描
SELECT COUNT(*) FROM large_table WHERE status = 1;
-- EXPLAIN: type=ALL → 遍历每一行判断

-- ✅ 建索引后：只扫索引树
ALTER TABLE large_table ADD INDEX idx_status (status);
SELECT COUNT(*) FROM large_table WHERE status = 1;
-- EXPLAIN: type=range, key=idx_status, Extra=Using where; Using index
```

### 9.2 近似计数（可容忍误差）

| 方案 | 精度 | 适用场景 |
|------|------|----------|
| `SHOW TABLE STATUS` | 低（缓存导致偏差） | MyISAM 快速估算 |
| 随机采样 × 膨胀系数 | 中 | 运营后台 Dashboard |
| `EXPLAIN table WHERE ...` | 较高 | 预估行数范围 |

> [!NOTE] InnoDB 的 COUNT(*)
> InnoDB 没有维护表级别行数（因为有 MVCC，不同事务看到的行数可能不同）。`COUNT(*)` 需要实际扫描。对于高并发大表，考虑**异步统计表**或**Redis 计数器**。

## 10. INSERT 批量优化

```sql
-- ❌ 逐条插入（N 次网络往返 + N 次事务提交）
INSERT INTO orders (...) VALUES (...);
INSERT INTO orders (...) VALUES (...);
INSERT INTO orders (...) VALUES (...);

-- ✅ 批量 INSERT（1 次网络往返 + 1 次事务）
INSERT INTO orders (...) VALUES (...), (...), (...);

-- ✅ Go 中分批次提交
for i := 0; i < len(items); i += 500 {
    batch := items[i : min(i+500, len(items))]
    db.Model(&Order{}).Create(batch)
}
```

## 11. CASE WHEN 代替多次查询

```sql
-- ❌ 应用层多次查询
countPending  = db.Where("status='pending'").Count()
countShipped  = db.Where("status='shipped'").Count()
countCompleted = db.Where("status='completed'").Count()

-- ✅ 单次查询 + 服务端处理
SELECT
    SUM(CASE WHEN status = 'pending'  THEN 1 ELSE 0 END) AS pending,
    SUM(CASE WHEN status = 'shipped'  THEN 1 ELSE 0 END) AS shipped,
    SUM(CASE WHEN status = 'completed' THEN 1 ELSE 0 END) AS completed
FROM orders;
```

## 改写原则总结

```mermaid
mindmap
    root((SQL 改写<br/>核心原则))
        早过滤
            WHERE 先行
            减少中间结果
        走索引
            避免函数包裹列
            OR 拆 UNION ALL
            LIKE 前缀匹配
        少回表
            Covering Index
            SELECT 指定列(非*)
        分批量
            批量 INSERT
            延迟关联
            游标分页
        换思路
            EXISTS vs JOIN
            CASE WHEN vs 多次查询
            子查询转 JOIN
```

## 关联笔记

- [[hhs/MySQL/03-索引与查询优化/15-EXPLAIN 完全指南]] — 改写后验证效果的必备工具
- [[hhs/MySQL/03-索引与查询优化/16-慢查询日志分析]] — 从慢日志中发现需要改写的 SQL
- [[hhs/MySQL/03-索引与查询优化/18-深分页优化]] — 游标分页的专项深入
- [[hhs/MySQL/03-索引与查询优化/12-B+Tree 索引原理]] — 理解索引走与否的根本原因
- [[hhs/MySQL/08-工程实践/40-常见踩坑]] — 生产环境中的典型错误写法合集
- [[hhs/GORM/15-性能优化]] — GORM 层的批量操作优化