云数据库中存储过程性能差异源于架构对固有特性的放大：执行计划缓存更稳定但参数嗅探更难察觉，网络延迟降低削弱“减少往返”优势，而复杂逻辑在高并发下易争抢资源。
云数据库里用存储过程，性能表现差异确实大——但不是“云数据库本身让存储过程变快或变慢”，而是云架构放大了存储过程的固有特性，让优势更明显、短板也更扎眼。
云数据库的执行计划缓存机制更稳定，但参数嗅探问题更难察觉
云数据库（如 PolarDB、Aurora）普遍采用共享缓冲池+全局执行计划缓存，sp_add_book这类简单存储过程首次编译后，后续调用几乎不触发重编译。但一旦遇到参数分布倾斜（比如某次传入 '2025' 查全年数据，下次传 '2025-06-15' 查单日），缓存计划可能严重失优。本地 MySQL 还能靠 DBCC FREEPROCCACHE 或重编译提示强制刷新，云数据库通常不开放底层控制，只能靠加 OPTION (RECOMPILE) 或拆分逻辑规避。
- 阿里云 PolarDB for MySQL 8.0 默认启用 query cache，但对存储过程无效；需依赖 optimizer hints 控制计划选择
- AWS RDS for SQL Server 允许在存储过程中显式使用
WITH RECOMPILE，但会抵消预编译优势 - 参数嗅探典型症状：相同存储过程，不同参数下耗时从 200ms 跳到 8s，且
sys.dm_exec_query_stats显示同一plan_handle多次复用
网络延迟降低后，存储过程的“减少往返”优势反而弱化
云数据库内网延迟常低于 0.5ms（如 PolarDB RDMA 网络），此时调用一次存储过程省下的那几次 round-trip，实际节省不足 1ms。反倒是复杂存储过程内部多层嵌套循环、临时表扫描，在高并发下更容易挤占 shared buffer 和 CPU 时间片。
- 简单查询（如单表
SELECT * FROM t_book WHERE bookid = ?）用存储过程 vs 直接 SQL，云环境下性能差异通常 - 涉及 5 张表 JOIN +
GROUP BY+ 窗口函数的报表逻辑，存储过程仍可比应用层拼 SQL 快 30%~40%，主因是中间结果集不落地、避免序列化传输 - 注意：云数据库的连接池（如 RDS Proxy）可能缓存客户端连接，但不缓存存储过程执行上下文，每次调用仍需完整上下文初始化
云平台自动扩缩容对存储过程资源争抢更敏感
云数据库计算节点弹性伸缩时，存储过程占用的内存（如 TEMPDB 空间、排序区）和 CPU 时间片分配策略会动态调整。一个长期运行的存储过程可能在扩容瞬间被中断，或在缩容时因资源回收失败而报 Query execution was interrupted。
- MySQL 云服务中，
max_execution_time默认值常设为 30s，超时即杀，而本地库可能设为 0（不限制） - 避免在存储过程中做长耗时操作（如遍历百万行游标），改用批量分页 + 应用层协调
- 云厂商提供的性能洞察工具（如 PolarDB 的 Performance Insight）能定位存储过程 CPU 占比突增，但无法直接看到过程内哪一行 PL/SQL 耗时高
真正容易被忽略的点：云数据库的备份一致性机制（如 PolarDB 的 Redo 日志实时同步）会让存储过程中的事务提交行为更不可预测——看似成功的 COMMIT，可能在跨节点同步完成前就返回客户端，导致应用层误判。这不是性能问题，但会让性能优化失去意义。
