如何定位导致Azure SQL Database DTU达100%的查询？
2026-8-10
分析与优化建议
判断是否为目标查询导致DTU耗尽
DTU是CPU、内存、磁盘IO的综合度量，CPU使用率低但DTU拉满，通常说明磁盘IO（数据读取/日志写入）或内存压力是瓶颈。要确认是否是图片3中的查询导致，可以做以下操作：
- 查看该查询的逻辑读/物理读次数：在Azure SQL中用
sys.dm_exec_query_stats或Query Store查看，高物理读会消耗大量IO资源，直接推高DTU。 - 观察负载测试期间的日志写入速率：如果该查询涉及大量INSERT/UPDATE/DELETE，日志IO可能占满DTU配额。
- 对比该查询的执行频率：单条查询DTU占比低，但如果并发执行次数极多，累计起来会耗尽DTU。
优化查询的具体步骤
检查并添加合适的索引
- 用
sys.dm_db_missing_index_details查看该查询的缺失索引建议，针对过滤条件、JOIN字段添加非聚集索引，减少物理读次数。 - 避免
SELECT *，只查询需要的字段，降低数据传输量和IO消耗。
- 用
优化查询执行计划
- 查看查询的实际执行计划，检查是否存在表扫描、键查找等低效操作，尝试重写查询（比如调整JOIN顺序、用CTE替代子查询）。
- 如果是批量写入操作，考虑改为批量提交（比如每次提交1000条而非单条提交），减少日志IO的频繁刷新。
利用Azure SQL的内置工具定位瓶颈
- 打开Query Store，筛选负载测试时间段的TOP资源消耗查询，确认目标查询是否在列。
- 查看Azure Portal中的数据库指标：重点看“数据IO百分比”“日志写入百分比”，如果其中一项接近100%，说明IO是DTU耗尽的原因。
调整查询并发策略
- 如果该查询是高并发场景，考虑添加查询提示（比如
MAXDOP控制并行度），避免过多并发请求抢占IO资源。 - 对只读类查询，考虑使用只读副本分流负载，减轻主库的IO压力。
- 如果该查询是高并发场景，考虑添加查询提示（比如
内容的提问来源于stack exchange，提问作者Jorge Silva
相关产品推荐
相关产品推荐
