查询优化

一、查询优化的第一性原理（原理层 · 稳定）

1.1 查询性能的本质公式

查询性能 ≠ SQL 执行速度查询性能 = 数据访问成本 + 计算成本 + 协调成本

这是所有数据库、所有版本、所有引擎都成立的第一性原理。

成本类型本质解释常见表现
数据访问成本访问了多少数据扫描行数、回表、随机 IO
计算成本对数据做了多少处理排序、聚合、表达式计算
协调成本多对象协作的代价锁等待、JOIN、中间结果

查询优化的全部目标：👉 用尽可能低的代价，得到足够准确的结果。

1.2 一个更底层的不变量

性能问题，本质是“无效数据的代价”

优化 ≠ 更快执行优化 = 更少做无意义的工作

二、查询优化的三层认知模型（结构层 · 稳定）

查询优化├── 逻辑层：你“想要什么”├── 执行层：数据库“如何做”└── 物理层：数据“如何存”

这是理解所有优化手段的认知骨架。

三、逻辑层优化：减少“想要的东西”（抽象层）

3.1 结果集裁剪原则（最重要）

越早裁剪，越低成本

裁剪方式原理
列裁剪减少数据传输与内存占用
行裁剪减少扫描、排序、JOIN
条件前推减少中间结果规模

设计原则：

3.2 大查询拆分原则

不要一次性处理峰值负载

将一个“资源洪峰”拆解为多个“小波峰”：

👉 本质是 时间换空间、稳定性换复杂度

四、执行层优化：减少“如何做”的成本（架构层）

4.1 MySQL 执行架构（稳定认知）

SQL → 解析（Parser） → 预处理（Preprocessor） → 优化（Optimizer） → 执行（Executor） → 存储引擎（Storage Engine）

关键认知：

4.2 扫描行数：执行层最重要指标

扫描行数 ≫ 返回行数 = 性能风险

衡量手段：

理想状态：

扫描行数 ≈ 返回行数

4.3 覆盖索引的本质

避免回表 = 避免随机 IO

覆盖索引不是“技巧”，而是一种执行路径优化：

4.4 JOIN 的本质代价

JOIN 是中间结果放大器

JOIN 的真实成本来自：

设计原则：

五、物理层优化：减少“数据如何存”的摩擦（实现层）

5.1 排序的真实成本模型

排序不是比较，而是搬运数据

排序代价由三部分构成：

  1. 数据量
  2. 数据宽度
  3. 临时空间

核心原则：

5.2 临时表与内存边界

所有“内存操作”都有溢出成本

👉 本质是 资源配额管理问题

六、优化器：能力、边界与理性使用（哲学层）

6.1 优化器的工作假设

优化器依赖：

但它不知道业务真实分布。

6.2 为什么不要迷信优化器提示

Hint 是“冻结假设”

设计哲学：

只有在“结构性误判”时，才干预优化器

七、典型查询模式的本质分析（模式层）

7.1 COUNT 的哲学

COUNT 的成本 = 遍历成本

架构性解法：

7.2 分页的核心矛盾

OFFSET 的本质是“丢弃成本”

正确思路：

7.3 IN / 子查询的风险本质

优化器无法准确评估“组合爆炸”

👉 本质是 估算失败导致路径错误

八、查询优化的决策框架（方法论）

查询慢├─ 数据访问多？│   ├─ 索引设计│   ├─ 条件裁剪│   └─ 数据分布├─ 中间结果大？│   ├─ JOIN│   ├─ 排序│   └─ 分组├─ 协调成本高？│   ├─ 锁│   ├─ 事务│   └─ 网络└─ 架构问题？    ├─ 缓存    ├─ 汇总    └─ 异步

九、演进视角：哪些知识会过期，哪些不会

会过期的

不会过期的

关联内容（自动生成）