SQL优化分析学习
文章目录
- 前言
- 一、STATISTICS PROFILE 执行方式
- 关键性能对比
- 二、STATISTICS PROFILE主要字段
- 三、SHOWPLAN_XML 执行计划
- 四、总结
前言
我知道的分析SQL的指令有4个，但我用的一直比较迷糊，今天有时间，决定学习、记录一下。
SET STATISTICS PROFILE ON --1、统计信息概况
SET STATISTICS IO ON --2、统计输入/输出
SET STATISTICS TIME ON --3、统计时间
SET SHOWPLAN_XML ON --4、查询执行计划
2和3 并没有什么出彩的地方。主要是1、4的分析
一、STATISTICS PROFILE 执行方式
⚠️这是一个统计性质的视图，能够体现查询复杂性。
可以看出 PROFILE 给的字段虽然多，但有用的就几个
PhysicalOp列 和 LogicalOp列 : 分别表示物理操作符和逻辑操作符。逻辑操作符表示优化器的意图，物理操作符表示实际执行方式。
这里主要看PhysicalOp就行了，我将类型挨个解读：
1. Compute Scalar: 计算标量
如数学运算、函数调用、类型转换等
UnitPrice * Quantity AS Total, -- 计算表达式
CONVERT(VARCHAR, OrderDate) -- 类型转换。
2、Hash Match: 哈希匹配
大表 JOIN（尤其无合适索引时）
GROUP BY 聚合
UNION / DISTINCT 去重
3、Merge Join: 合并连接
中到大表 JOIN（双方均有索引排序）
需要有序输出的查询（如 ORDER BY 与 JOIN 键一致）
4、Sort: 排序
ORDER BY 子句
为 Merge Join 或 Stream Aggregate 准备有序输入
5、Clustered Index Scan: 聚集索引扫描
无可用索引的查询（如 SELECT * FROM table）
WHERE 条件无法使用索引（如函数操作列）
6、Stream Aggregate: 流聚合
排序后 数据流上进行聚合（如 SUM/COUNT/GROUP BY）。
7、Clustered Index Seek: 聚集索引查找
SELECT * FROM Orders WHERE OrderID = 10248 -- OrderID是聚集索引键
8、Index Scan :索引扫描
9、Index Seek:索引查找
关键性能对比
| 操作符 | 适用场景 | 资源消耗 | 优化目标 |
|---|---|---|---|
Clustered Index Seek | 精确查找 | ⭐️⭐️⭐️⭐️⭐️ (低) | 首选操作 |
Hash Match | 大表JOIN/聚合 | ⭐️⭐️ (高) | 避免内存溢出 |
Merge Join | 有序数据JOIN | ⭐️⭐️⭐️ (中) | 确保输入已排序 |
Clustered Index Scan | 全表访问 | ⭐️ (极高) | 转化为Seek或非聚集索引 |
⚠️ 聚合是没办法，但全表扫描应该尽量避免
二、STATISTICS PROFILE主要字段
了解了PhysicalOp执行方式，倒回来再看。
Hash Match、Index Scan已经算高效操作了，
sort排序、Compute Scalar运算、Join(Merge Join)，往往不可避免
但Clustered Index Scan 的全表扫描，则需优化索引。
还好这里的子表只有27642行，并不离谱。但也是数据优化的突破口。
其他字段
- ROW:实际处理的物理行数 ( 当然越少越好)
- Executes: 实际被执行的次数 (大于1,就需要注意是否冗余操作)
- Argument: 详细信息，（便于对PhysicalOp的判断）
三、SHOWPLAN_XML 执行计划
点开查询给的链接，主要是 21%+72% 占用了93%的资源。
Hash Match的聚合算高效操作，所以 Clustered Index Scan的全部操作有很大的优化空间。
换句话说，扫描全表，占行锁，也会影响其他人的读写。
四、总结
STATISTICS PROFILE ON ，优化方向在：减少查询行数、执行次数、优化执行方式(走索引减少全表扫描)
SET SHOWPLAN_XML ON ，是同数据下的，另外一种直观体现，优化方向更多在计划顺序、资源占用。
这两种方式，数据一致、但各有侧重。