AWS免费层SQL Server子查询执行延迟原因咨询

先还原下你的场景：两张各60万行的表，本地跑这条查询耗时不到1秒，AWS免费层却要4秒：

SELECT * FROM XYZ WHERE XYZ.milisecDateTimeBigInt = (SELECT MAX(ABC.milisecDateTimeBigInt) FROM ABC WHERE ABC.ID = 1)

而你用先存变量的写法就解决了：

DECLARE @a bigint; 
SELECT @a = MAX(ABC.milisecDateTimeBigInt) FROM ABC WHERE ABC.ID = 1;
SELECT * FROM XYZ WHERE XYZ.milisecDateTimeBigInt = @a;

核心原因分析 #

• 执行计划的差异（最关键）
  虽然你的子查询看起来是只返回单个值的标量子查询，但AWS免费层的SQL Server优化器可能因为资源受限、统计信息更新不及时等原因，错误选择了关联执行计划——也就是对XYZ表的每一行都执行一次子查询去匹配最大值。60万行的话，相当于重复执行了60万次MAX查询，直接把有限的CPU和IO资源耗尽，延迟自然飙升。
  而用变量的写法，相当于强制优化器把查询拆成两步：第一步只执行一次MAX查询拿到结果，第二步用这个固定值去过滤XYZ，如果XYZ.milisecDateTimeBigInt上有索引，第二步就是高效的索引查找，哪怕资源有限，也不会重复执行子查询。

• AWS免费层的资源限制
  免费层的SQL Server实例在CPU、内存、IOPS上都有严格配额，远不如你本地的数据库配置。当执行计划需要大量重复计算时，本地能靠充足资源快速完成，而免费层的资源瓶颈会被无限放大，直接体现为耗时翻倍。

• 缓存与IO差异
  本地数据库可能已经把两张表的热点数据缓存到内存中，而AWS免费层实例的内存很小，大部分数据需要从磁盘读取，IO速度本身就慢，再加上执行计划的低效，更是雪上加霜。

额外优化建议 #

• 给ABC.ID和ABC.milisecDateTimeBigInt建联合索引：CREATE INDEX IX_ABC_ID_DateTime ON ABC(ID, milisecDateTimeBigInt)，这样MAX查询能直接从索引拿到结果，不用扫全表。
• 给XYZ.milisecDateTimeBigInt建单独索引，进一步加速过滤步骤。

内容的提问来源于stack exchange，提问作者MD TAHMID HOSSAIN