SQL Server、MySQL升级及C#调用中存在隐式依赖导致的兼容性断裂：参数类型转换、NULL处理、排序规则、执行计划、DEFINER权限、sql_mode变更、OUTPUT参数长度未显式指定等均可能引发结果不一致或运行失败。
升级存储过程本身不会自动破坏调用方，但多数兼容性断裂来自隐式依赖——比如参数类型隐式转换、NULL处理变化、排序规则敏感度提升、或执行计划因兼容级别切换而劣化。关键不是“能不能跑”，而是“结果和行为是否一致”。
SQL Server 升级后 COMPATIBILITY_LEVEL 变更引发的行为漂移
从 130 升到 150 后，CONVERT_IMPLICIT 警告变错误、datetime 字面量解析精度变高、GROUP BY 对非确定列容忍度下降。这些不报错，但结果可能少行或多空值。
- 升级前先执行
ALTER DATABASE CURRENT SET COMPATIBILITY_LEVEL = 150，再立刻运行DBCC FREEPROCCACHE（仅验证环境），否则旧计划缓存会掩盖真实行为 - 在过程定义末尾加
OPTION (RECOMPILE)，确保每次执行都基于当前兼容级别生成计划，避免“看起来一样，实际走错索引” - 检查
sys.dm_exec_query_stats中该过程的last_execution_time和execution_count，确认是否真在新级别下被重编译
MySQL 8.0 升级中 DEFINER 和 sql_mode 的静默失效
DEFINER='root@localhost' 在 8.0 默认拒绝执行；sql_mode 新增 ONLY_FULL_GROUP_BY 会让原来能跑的 GROUP BY id 直接报错——这不是结果不一致，是根本调不通。
- 导出前用 8.0 的
mysqldump连接 5.7 实例，必须带--routines --set-gtid-purged=OFF，避免写入已废弃的mysql.proc - 批量替换
DEFINER：用SELECT CONCAT('CREATE DEFINER=CURRENT_USER PROCEDURE ', ROUTINE_NAME, ...)重构语句，别硬改 dump 文件 - 在目标库执行前，先设
SET sql_mode = (SELECT REPLACE(@@sql_mode, 'ONLY_FULL_GROUP_BY', ''))，再验证逻辑，最后逐步收紧
C# 或 Java 调用时 output 参数长度未显式指定
SQL Server 中 OUTPUT 参数若未在客户端代码里设置 Size，比如 cmd.Parameters.Add("@name", SqlDbType.NVarChar).Size = 50，实际只取第一个字符——这问题在低版本可能偶然“凑巧”对，升级后立即暴露。
- 所有
nvarchar/varchar类型的OUTPUT参数，必须显式设Size，且不能小于过程定义中的长度（如过程里是nvarchar(100)，客户端至少设Size = 100） - 避免用
ParameterDirection.ReturnValue混淆Output参数——前者对应RETURN整数，后者才是变量赋值 - 在过程内加
IF LEN(@output_param) DATALENGTH(@output_param)/2 RAISERROR('UTF-16 truncation risk', 16, 1)做早期探测
最危险的兼容性断裂不是语法报错，而是数据语义偏移：比如旧版把 '2023-01-01' 当成 datetime 截断毫秒，新版当 datetime2 保留；或者排序规则从 utf8mb4_general_ci 切到 utf8mb4_0900_as_cs，导致字符串比较突然区分大小写。这类问题必须靠字段级数据特征比对，不能只看行数和列名。
