当 Azure SQL Database 出现性能问题时，仅检查 CPU 利用率是不够的。查询可能将大部分时间花费在等待上，而非执行，即使资源指标表现健康。关键问题在于耗时（elapsed time）具体花费在哪里，而不仅仅是 CPU 的使用量。资源利用率应是初步检查点，通过查询 sys.dm_db_resource_stats 可识别 CPU、数据 I/O、日志 I/O、内存或工作线程限制是否接近饱和。若资源未饱和，则需进一步分析等待统计信息。等待模式（如内存争用相关的 PAGELATCH_* 或阻塞相关的 LCK_M_）指明了需要深入调查的方向。PAGEIOLATCH_ 等待与物理 I/O 相关，而 PAGELATCH_* 等待涉及对已驻留内存页面的同步，可能由单个热点页的高并发引起。查询执行的频率同样显著影响性能，而不仅仅是单个查询的成本。Query Store 对于追踪查询执行历史至关重要，可随时间比较持续时间、CPU 使用量及等待行为。若查询耗时较长但 CPU 使用量较低，应调查 ASYNC_NETWORK_IO 等等待类型，这通常表明客户端应用程序未能及时消费结果。测量获取第一行时间与获取最后一行时间之间的差异，有助于区分数据库响应时间与结果消费时间。持续性阻塞（即会话等待其他事务）即使 CPU 较低，也可能导致感知上的缓慢。对数据库进行扩展可能通过改善整体资源可用性来掩盖根本原因，而非解决底层的性能瓶颈。实用的工作流程包括：定义事件窗口、检查资源、对比 CPU 与耗时、识别主导等待类型、检查阻塞、使用 Query Store、检查执行计划以及调查应用程序。归根结底，有效排查 Azure SQL 性能问题的关键在于理解时间具体花费在哪里，而不仅仅是数据库看似有多繁忙。