转换后的查询即使语法有效，也可能是错误的。
这是数据库迁移中最重要的经验之一。不同数据库引擎可能接受相似的 SQL，却因 NULL 处理、日期规则、数据类型、舍入、排序或隐式转换不同而产生不同结果。
在将转换后的 SQL 视为可用于生产环境之前，请使用以下清单进行检查。
1. 确认查询的用途
写下源查询预期要完成的任务。
它是计算收入、查找逾期发票、准备仪表板，还是更新账户状态？明确的业务结果可以帮助审核人员在转换过程中保护关键目标。
2. 保存具有代表性的源结果
使用包含常规和异常情况的数据运行原始查询。
包括：
• NULL 值
• 空字符串
• 零值和负数
• 临界日期
• 重复记录
• 较大的数值
• 相关情况下的非 ASCII 文本
保存结果，以便与目标数据库进行比较。
3. 比较行数
先从最简单的信号开始。如果源查询返回 2,410 行，而目标查询返回 2,397 行，说明发生了变化。
行数不同通常指向连接行为、筛选条件、NULL 比较、日期边界或重复数据处理方面的问题。
4. 检查计算值
比较总计、平均值、百分比和分组结果。
特别关注整数除法、小数精度、舍入、溢出和隐式类型转换。这些差异可能产生较小的误差，并在大型数据集上变得显著。
5. 检查 NULL 和空字符串行为
数据库对 NULL 值和空字符串的处理方式并不总是相同。
检查表达式、连接、比较、聚合函数和条件逻辑。查询可能能够正常运行，却在无提示的情况下排除或改变某些值。
6. 测试日期和时间逻辑
日期运算是迁移中最常见的问题领域之一。
验证：
• 增加或减去的时间间隔
• 时区处理
• 月和年的边界
• 周编号
• 日期截断
• 当前日期和当前时间戳的行为
尽可能使用固定的测试日期，以便比较结果能够重复。
7. 确认排序和文本比较
排序规则和大小写敏感性可能影响 ORDER BY、相等性检查、分组和重复数据检测。
如果真实数据集中存在相关值，请测试大小写不同、带重音符号以及包含空白的文本。
8. 检查数据库特有功能
仔细检查供应商特有的函数、临时表、过程式 SQL、动态 SQL、JSON 操作和特殊数据类型。
这些领域可能无法安全地进行一对一转换，通常需要开发人员或数据库专家作出最终决定。
9. 检查诊断信息，不要忽略它们
警告不一定意味着转换失败，而是说明翻译后的 SQL 值得进一步关注。
将诊断信息作为审核队列。在处理外观方面的修改之前，先解决风险最高的行为差异。
10. 在部署前进行测试
在包含代表性数据的安全环境中运行转换后的 SQL。比较输出，并测试相关报表、应用程序和计划任务。
最终工作流程应为：
转换
审核
比较
测试
部署
转换质量不只由语法是否有效来衡量，还取决于目标 SQL 在多大程度上可靠地保留了源 SQL 的含义。
