我之前碰到过类似的Azure SQL性能问题，结合你的场景，给你梳理几个可能的排查方向：

• 索引碎片或统计信息过时：单条查询快不代表高流量下没问题。如果你的Tip表有频繁的插入、更新操作，索引碎片会慢慢累积，让SQL引擎需要扫描更多数据页；另外自动更新统计信息可能没跟上750万条数据的变化，导致查询引擎生成的执行计划不是最优的。可以跑这两个命令排查：

  -- 检查Tip表的索引碎片情况
  SELECT name, avg_fragmentation_in_percent 
  FROM sys.dm_db_index_physical_stats(DB_ID(), OBJECT_ID('Tip'), NULL, NULL, 'DETAILED');
  -- 查看统计信息的最后更新时间
  SELECT name, stats_date(object_id, stats_id) 
  FROM sys.stats WHERE object_id = OBJECT_ID('Tip');
  

  如果碎片率超过30%，建议重建索引；10%-30%可以整理索引，同时手动更新统计信息：UPDATE STATISTICS dbo.Tip WITH FULLSCAN;

• 高并发下的资源争用：单条查询<250ms是低并发场景的结果，高流量时可能出现两种情况：

  • 锁阻塞：如果同时有大量查询和写入操作（比如插入新的Tip记录），会出现锁等待，导致查询排队变慢。可以用SELECT * FROM sys.dm_tran_locks WHERE resource_associated_entity_id = OBJECT_ID('Tip');查看锁等待情况；
  • 资源瓶颈：Azure SQL的DTU/vCPU、内存、IOPS在高流量时可能达到服务层的上限，导致查询无法及时得到资源。你可以在Azure门户的SQL数据库监控面板，查看CPU使用率、数据IO、日志IO的峰值，是否接近当前服务层的阈值。

• 执行计划在高并发下退化：单条查询的最优执行计划，在高并发场景下可能出现退化，比如参数嗅探导致执行计划不适合所有MemberId的查询，或者SQL引擎切换成了效率更低的扫描操作。建议开启查询存储（Query Store），捕获高流量时段的执行计划，和单条查询的计划对比，看看是否存在计划回归的情况。

• 索引覆盖度不足：虽然你有MemberId的索引，但如果查询需要返回Slot、PeriodKey等其他列，SQL Server可能需要做键查找（Key Lookup）。单条查询的键查找影响不大，但高并发下大量这类操作会消耗大量IO和CPU。可以查看查询的执行计划，如果存在键查找，考虑创建包含所需列的覆盖索引，比如：

  CREATE NONCLUSTERED INDEX IX_Tip_MemberId_Included 
  ON dbo.Tip(MemberId) 
  INCLUDE (Slot, PeriodKey); -- 根据实际查询需要的列调整
  

• 弹性池或自动缩放的延迟：如果你的数据库在弹性池中，高流量时可能其他数据库占用了池中的资源，导致你的数据库得不到足够的算力；如果开启了自动缩放，流量突增时可能缩放操作有延迟，出现短暂的性能下降。

内容的提问来源于stack exchange，提问作者Dirk Boer