SQL SERVER SQL 优化指南 四句真言 （SQL 优化系列 2）

❝

开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共3300人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7群均已爆满，开8群近400 9群 200+，开10群PolarDB专业学习群100+)

SQL 优化四字真言系列

PostgreSQL SQL 优化指南 四句真言（SQL 优化系列 1）

上期说完PostgreSQL 数据库，这期咱们说说MSSQL，也就是SQL SERVER的SQL优化指南。SQL SERVER 作为中小企业，现在应该是外企最喜欢的数据库产品，是有道理的，他比ORACLE更便宜，但不比ORACLE在SQL计算上差，同时基于WINDOWS的系统之上，他的操作更多的是鼠标化的方式，当然命令的方式也很丰富。这里最值得称赞的事，MSSQL本身的自动化能力很强，尤其在最新版本的2025，SQL的优化已经可以基本AI话，自动化，历史数据分析化了。

但SQL SERVER的SQL优化也有自己的特色，这里也有四句真言：

索引为王，聚集最快，要想更快就上包含，

 统计信息，一定要准，真要不行，马上RCL，

 并行厉害，但要有度，单条语句也能控制， 

日志重要，性能关键，实在不行给点好盘。

作为SQL SERVER的老手，我自己还藏了一招，四句真言里面的第五句是，真要不行，CI 独上。

下面我们逐步分解者几句，并找案例

1  SQL SERVER 中索引是提高查询速度的关键，而SQL SERVER里面的索引有一个特别有意思的地方，这点是搞ORACLE, PG DBA所不理解，不明白，想不通的地方。 聚集索引，也就是SQL SERVER 可以和MySQL一样在建表时将主键和行的物理位置进行绑定，也就是说，在MYSQL中的一些优化原理，在MSSQL的聚集索引上也是有效的，比如UPDATE + 聚集索引条件，他一定比你UPDATE + 二级索引要快，这也是MSSQL的DBA 上手MySQL容易得一个原因（仅限SQL执行层面）。

同时MSSQL 还有一个原来的查询的杀手锏，include索引，这个功能PG到PG11才引入进来。MSSQL 的一些 SELECT  一堆字段的优化就可以通过include索引来解决回表的问题，通过索引就完全返回数据，对于一些大表和字段多的查询是有利的。

 CREATE TABLE Orders (
 OrderID INT PRIMARY KEY,
 CustomerID INT NOT NULL,
 OrderDate DATETIME NOT NULL,
 Amount DECIMAL(10,2) NOT NULL
);

比如上面的建表，在MSSQL ，同样是查询

SELECT *
FROM Orders
WHERE CustomerID = 1001;

对比

SELECT *
FROM Orders
WHERE OrderID = 1001;

那个更快，在有主键 orderID 和 CustomerID 二级索引的情况下，那一定是主键的查询更快，这是ORADLE 和 PG DBA所一时间不能理解的，MySQL DBA会明白这个道理。

而如果非要比较，如果在不显示主键的情况下,建立include索引必然是要比单独建立CustomerID索引要快。

CREATE NONCLUSTERED INDEX IX_Orders_CustomerID_Include
ON Orders(CustomerID)
INCLUDE (OrderDate, Amount);

统计信息对于任何数据库都很重要，一般来说不是突然的插入，更改，删除大量的数据是不会导致MSSQL的统计信息不对导致SQL操作的执行计划失误的。但我们还是要留一手，

MSSQL的统计信息分为直方图，密度向量，和更新行数等信息，这里我们可以手动去触发一个表的统计信息更新如，

UPDATE STATISTICS dbo.Orders;

如果你不手动，那么自动更新的方式会以默认约 20% + 500行 变化时更新统计信息的信息。但还是会在一些较大场景下，不及时的情况，所以手动更新统计信息的方式还是要会的。

-- 开启自动创建统计信息
ALTER DATABASE MyDB SET AUTO_CREATE_STATISTICS ON;

-- 开启自动更新统计信息
ALTER DATABASE MyDB SET AUTO_UPDATE_STATISTICS ON;

-- 开启异步更新统计信息（不阻塞查询）
ALTER DATABASE MyDB SET AUTO_UPDATE_STATISTICS_ASYNC ON;
建议：

OLTP系统 → AUTO_UPDATE_STATISTICS ON 即可

大规模OLAP / 数据仓库 → 建议定期手动更新（FULLSCAN），并可考虑 ASYNC 避免阻塞

同时是MSSQL 对于数据倾斜的情况有一些解决方案，这里就不在初级的指南里面讨论了。

关于四句真言中的第二句的RCL,意思是抛弃执行计划的缓存，每次执行语句都需要进行重新编译。

SELECT *
FROM Orders
WHERE CustomerID = @cid
OPTION (RECOMPILE);

第三句中的并行很厉害，SQL SERVER中的并行的确在这么多数据库中，我个人认为是将并行用到极致的，甚至到了一种病态的状态，到了并行滥用的境地。对于MSSQL的并行在之前的使用经验里面基本上复杂的SQL，所有的CPU单元都给你用上，到时IOPS出现问题的情况比比皆是，IOPS超高又会导致累积现象，让SQL运行越来越慢，越慢越DOP。所以一些复杂的SQL，建议控制一下DOP的使用。

我们可以在一些OLAP的语句中直接加入MAXDOP的参数如下

SELECT ... 
FROM table
OPTION (MAXDOP 8);  -- 指定并行度

数字式这个SQL可以最大使用多少CPU线程来并行执行这条SQL。一句话合理控制并行度MAXDOP的参数，关注一些SQL的数据倾斜，减少Gather Streams的时间，可以从全局上先控制 max degree of parallelism (MAXDOP) 的大小，然后在从一些语句上进行细调找到合适DOP。

最后一句与一些语句的UPDATE的效率，INSERT，和DELETE的效率有关，再多的操作都是要串行写入LDF文件的，LDF文件的写入速度的快慢，就决定了你的事务中的UPDATE INSERT DELETE语句的执行效率，这里可以把日志文件放到单独的 NVME ，SSD磁盘上降低大事务，频繁小事务对于COMMIT的压力。

最后我们以一个案例结束，假设我们有以上的一些表，

customers(cust_id, name, country) → 用户

orders(order_id, cust_id, order_date, status, total_amount) → 订单

order_items(order_id, product_id, quantity, price) → 订单明细

products(product_id, category_id, name, price) → 商品

categories(category_id, name) → 商品分类

找出 最近一年内下过订单的客户，并且这些客户购买过 至少一个“电子产品”类的商品，再统计这些客户的订单总额。

SELECT c.cust_id,
       c.name,
       SUM(o.total_amount) AS total_spent
FROM customers c
JOIN orders o
  ON c.cust_id = o.cust_id
WHERE o.order_date >= DATEADD(year, -1, GETDATE())
  AND c.cust_id IN (
        SELECT o2.cust_id
        FROM orders o2
        JOIN order_items oi ON o2.order_id = oi.order_id
        JOIN products p ON oi.product_id = p.product_id
        JOIN categories cat ON p.category_id = cat.category_id
        WHERE cat.name = 'Electronics'
     )
  AND EXISTS (
        SELECT 1
        FROM orders o3
        WHERE o3.cust_id = c.cust_id
          AND o3.status = 'Completed'
     )
GROUP BY c.cust_id, c.name
HAVING SUM(o.total_amount) > 1000
ORDER BY total_spent DESC;

这样的语句在之前MSSQL的经验中经常遇到，主要有两个问题

1 IN 中的数据集太大执行效率慢的问题 2 Exists 子查询会多次扫描order表的问题

WITH cust_with_electronics AS (
    SELECT DISTINCT o2.cust_id
    FROM orders o2
    JOIN order_items oi ON o2.order_id = oi.order_id
    JOIN products p ON oi.product_id = p.product_id
    JOIN categories cat ON p.category_id = cat.category_id
    WHERE cat.name = 'Electronics'
)
SELECT c.cust_id,
       c.name,
       SUM(o.total_amount) AS total_spent
FROM customers c
JOIN orders o
  ON c.cust_id = o.cust_id
JOIN cust_with_electronics ce
  ON c.cust_id = ce.cust_id
WHERE o.order_date >= DATEADD(year, -1, GETDATE())
  AND EXISTS (
        SELECT 1
        FROM orders o3
        WHERE o3.cust_id = c.cust_id
          AND o3.status = 'Completed'
     )
GROUP BY c.cust_id, c.name
HAVING SUM(o.total_amount) > 1000
ORDER BY total_spent DESC;

这样修改的好处主要在 1 使用CTE方式可以先对买过电子产品的用户进行筛选，并且语句观感也更加的清晰。 2 将之前的IN改成JOIN，IN 与 JOIN 之间的效率关系，在这里就不多讲了，已经讲烂了。 3 EXISTS 属于办理案件，可以避免不必要的聚合。

但是 ，但是，但是，如果你使用是SQL SERVER 2022以上版本包含2022 那么我的语句根本不用改，新版本的SQL SERVER 支持了 QOE功能，可以自动把这些写的不怎么样的语句进行重写，同时通过AJ功能，自动适应Nested loop or Hash Join的方式，最后还可以使用2019版本提供的批模式执行，当然这里还么有用到物化索引，那个部分我就不想讲了，自己的留一个高技能留着。

同时还有一堆的新功能如 QS，psp，CI功能，这个就不讲了。

基于SQL SERVER在SQL执行中的智能化，AI化，之前文章也写过2025版本的厉害，相信更先进的SQL SERVER必定能让烂SQL优化更加不需要人工的介入。

SQL SERVER维保AI化，从一段小故事开始

SQL SERVER 2022 针对缓存扫描和Query Store 的进步，可以考虑进行版本升级

SQL SERVER 2025发布了， China幸亏有信创！

免费PolarDB云原生课程，听课“争”礼品，重塑云上知识，提高专业能力