无showplan权限时，如何优化SQL Server的复杂ad-hoc queries？

阿华AIGC实验室

2026-5-20

优化无执行计划权限下的SQL Server Ad-Hoc查询

嘿，能理解你现在的困境——要把跑半小时的ad-hoc查询压缩到5分钟以内，还没权限看执行计划那些核心DMV，只能靠INFORMATION_SCHEMA、系统目录视图和统计信息来优化，确实有点棘手，但绝对有办法！

1. 先摸透现有索引，找缺失/冗余点

没有执行计划，那就从索引的“基本面”入手，先搞清楚哪些字段有索引，哪些没有：

用这段脚本查所有用户表的索引和对应列：

SELECT 
    t.name AS TableName,
    i.name AS IndexName,
    STRING_AGG(c.name, ', ') AS IndexColumns,
    i.type_desc AS IndexType
FROM sys.indexes i
JOIN sys.tables t ON i.object_id = t.object_id
JOIN sys.index_columns ic ON i.object_id = ic.object_id AND i.index_id = ic.index_id
JOIN sys.columns c ON ic.object_id = c.object_id AND ic.column_id = c.column_id
WHERE t.is_ms_shipped = 0
GROUP BY t.name, i.name, i.type_desc
ORDER BY t.name, i.name;

对比你的查询：重点看WHERE过滤条件、JOIN连接字段、ORDER BY/GROUP BY分组排序字段，有没有高频用到但完全没被索引覆盖的字段？比如你每次都按CustomerID过滤，但这个字段连个非聚集索引都没有，那这就是首要优化点。
顺便排查冗余索引：比如两个索引都是以OrderDate开头，只是包含列略有重复，这种冗余索引会增加写操作的开销，也可能让SQL Server选错索引，能合并就合并。

2. 用STATISTICS TIME/IO精准定位瓶颈

这两个工具是你现在的核心武器，一定要用好：

每次调整前先开启统计：

SET STATISTICS TIME ON;
SET STATISTICS IO ON;

执行查询后，重点盯这几个关键指标：
- Logical Reads：逻辑读过高意味着SQL Server在反复扫描表或索引，这是性能差的典型表现，要想办法把扫描换成索引查找。
- CPU Time vs Elapsed Time：如果CPU时间远小于耗时，大概率是IO等待拖慢了查询，优先优化索引减少读操作；如果CPU时间接近总耗时，那问题可能出在复杂的计算逻辑上（比如嵌套子查询、大量函数调用）。
拆分查询测试：把大 query拆成几个小模块单独执行，看哪个模块的统计数据最差，先啃这个硬骨头。

3. 重构查询逻辑，砍掉不必要的开销

很多时候，查询慢不是因为索引，而是逻辑写得太臃肿：

把低效的IN子 query换成JOIN：尤其是子查询返回大量数据时，JOIN的执行效率通常远高于IN。
别在WHERE里对字段用函数：比如WHERE YEAR(OrderDate) = 2024会直接让OrderDate上的索引失效，改成WHERE OrderDate >= '2024-01-01' AND OrderDate < '2025-01-01'就能用上索引。
拒绝SELECT *：只查你需要的列，这样不仅减少数据传输，还能让索引实现“覆盖查询”（如果索引包含了所有需要的列，就不用回表查数据了）。
用临时表拆分大查询：如果是要对海量数据做分组统计，先把过滤后的核心数据插入临时表（#TempTable），再给临时表建合适的索引，最后在临时表上做统计——临时表的开销比直接在大表上操作小得多。

4. 检查统计信息是否过期

过时的统计信息会让SQL Server生成糟糕的执行计划，哪怕你看不到计划，更新统计也可能悄悄提升性能：

用这段脚本看统计信息的更新时间：

SELECT 
    t.name AS TableName,
    s.name AS StatName,
    s.last_updated,
    s.rows AS TotalRows,
    s.rows_sampled AS SampledRows
FROM sys.stats s
JOIN sys.tables t ON s.object_id = t.object_id
WHERE t.is_ms_shipped = 0;