AWS RDS SQL Server存储过程性能异常缓慢问题咨询：迁移后UDF调用语句性能差异排查

这个问题太典型了！我之前帮好几个迁移到AWS的客户排查过类似情况——明明索引配置全一致，RDS上的查询就是慢得离谱，甚至升级实例都没用。给你梳理几个最容易被忽略的原因，按优先级排查：

• SQL Server版本与补丁差异：本地和RDS的SQL Server版本、累积更新（CU）补丁可能不一致。比如某些版本对标量UDF的执行效率有bug，或者RDS默认的版本没有开启最新的优化特性。你可以在两边执行SELECT @@VERSION，仔细对比版本号和补丁级别，比如本地是SQL Server 2019 CU18，而RDS是2019 CU10，这种差异很可能导致UDF执行逻辑的性能差距。

• 标量UDF内联特性的开关差异：如果你的UDF是标量类型，SQL Server 2019及以上版本有个Scalar UDF Inlining特性，能把标量UDF转换成内联逻辑，性能提升好几倍。本地可能已经开启了这个特性，但RDS的数据库默认没开？你可以执行SELECT name, is_scalar_udf_inlining_enabled FROM sys.databases WHERE name = '你的数据库名'对比两边的设置，要是RDS这边是0，手动改成1试试。

• 执行计划缓存与参数嗅探问题：RDS和本地的执行计划缓存是完全独立的，很可能本地的执行计划是针对常用参数生成的最优计划，而RDS上因为参数嗅探，生成了适配其他参数的低效计划。你可以在SP的SELECT语句末尾加OPTION (RECOMPILE)强制生成新计划，或者用SET SHOWPLAN_XML ON导出两边的执行计划对比，看看RDS是不是走了全表扫描、嵌套循环等低效路径。

• 统计信息过时或精度差异：索引一致不代表统计信息一致！本地可能刚更新过统计信息，而RDS上的统计信息因为数据更新频率低或者自动更新阈值没触发，已经过时了，导致优化器生成错误的执行计划。手动执行UPDATE STATISTICS 你的表名 WITH FULLSCAN更新统计信息，再测试性能。另外也要检查AUTO_UPDATE_STATISTICS和AUTO_UPDATE_STATISTICS_ASYNC的设置是否和本地一致。

• 资源争用与IO特性差异：哪怕是高性能RDS实例，也可能存在共享环境的资源争用——比如同宿主机的其他RDS实例抢占CPU、内存或IO带宽。你可以去CloudWatch查看RDS的CPUUtilization、FreeableMemory、ReadLatency、DiskQueueDepth指标，看看有没有持续高负载的情况。另外，本地存储可能是NVMe SSD，而RDS如果用的是gp3存储，IOPS配置不足的话，读延迟会比本地高，尤其是UDF需要多次读取数据时，延迟会被放大。

• 网络延迟的累积效应：如果你的Lambda函数和RDS不在同一个VPC，或者跨AZ访问，每次UDF调用都会产生额外的网络延迟。尤其是UDF在循环里调用的话，几百次调用的延迟加起来就很可观了。检查Lambda和RDS的VPC配置，尽量放在同一个AZ，或者开启RDS Proxy减少连接开销。本地是直接访问数据库，没有网络跳点，这一点很容易被忽略。

• SQL Server核心配置差异：比如MAXDOP（最大并行度）、cost threshold for parallelism这些配置，本地和RDS可能不一样。RDS的MAXDOP默认是实例vCPU数的一半，而本地可能设置的更高，导致并行执行计划的差异。用sp_configure对比两边的配置，重点看与查询优化相关的选项。

内容的提问来源于stack exchange，提问作者Manu A N