SQL Server 的 T-SQL 生态非常成熟，很多企业的核心业务逻辑都写在存储过程、函数和视图里。迁移时，这些代码的改造量往往比数据迁移本身更让人头疼。
评估改造量不是数一下有多少个存储过程那么简单，需要按复杂度和依赖关系分级处理。
第一步：摸清家底
先做一次全面的代码盘点，统计以下内容：
统计完数量后，按复杂度分级：
第二步：识别不兼容的语法
T-SQL 有大量特有语法，在非 SQL Server 数据库中无法直接运行。需要重点关注：
语法差异
数据类型映射
函数差异
第三步：评估替代方案
不是所有 T-SQL 代码都需要一一对应地翻译。有些可以直接用目标数据库的等价写法，有些需要调整思路。
存储过程： 不同产品的存储过程支持程度不同。如果目标数据库支持存储过程，优先做语法翻译；如果不支持，需要改写为应用代码。改写时要注意事务边界的处理——存储过程中的事务在应用层需要用框架的事务管理来实现。
CLR 集成： 这是最难的部分。SQL Server 的 CLR 允许用 C# 写数据库逻辑，其他数据库基本不支持。迁移时需要把 CLR 代码改写为应用层代码或目标数据库支持的形式。如果 CLR 代码涉及复杂的数据处理逻辑，改写工作量可能很大。
Service Broker： SQL Server 的消息队列功能在其他数据库中没有直接对应。需要迁移到独立的消息中间件（如 Kafka、RabbitMQ）或应用内消息机制。
第四步：建立改造优先级
不是所有存储过程都需要在迁移第一天就改完。建议按以下优先级排序：
TiDB 在 SQL Server 迁移中的对应能力
TiDB 兼容 MySQL 协议，支持存储过程（从 v6.2 开始）和大部分常用 MySQL 语法，T-SQL 的改写可以参照 MySQL 语法体系来做映射。对于 CLR 集成和 Service Broker 等 SQL Server 特有功能，需要改为应用层实现。建议先用 TiDB 的兼容性检查工具对现有 T-SQL 做一次扫描，量化语法差异，再评估改造工作量。
如果你正在评估 SQL Server 迁移，建议先从存储过程和函数的复杂度盘点开始，再结合目标数据库的兼容性测试结果确定改造方案。