DB2 LUW（Linux/Unix/Windows）是三种 DB2 环境中最接近开放生态的版本，迁移技术难度相对可控。但 DB2 的数据类型和 SQL 语法有不少「看起来差不多、实际有差异」的细节，容易在迁移后才发现问题。
数据类型的隐藏差异
DECIMAL 精度
DB2 的 DECIMAL 默认精度是 DECIMAL(5,0)，而 MySQL 的 DECIMAL 默认是 DECIMAL(10,0)。如果建表时只写了 DECIMAL 没有指定精度，迁移后存储范围会不同。
字符类型
DB2 的 VARCHAR 和 CHAR 有明确的字节长度语义。MySQL 的 VARCHAR 在 utf8mb4 下，长度是字符数而不是字节数。同样声明 VARCHAR(100)，DB2 最多存 100 字节，MySQL 最多存 100 个 utf8mb4 字符（最多 400 字节）。
日期时间类型
DB2 的 TIMESTAMP 精度是微秒（6位小数），MySQL 的 DATETIME(6) 也是微秒，但 MySQL 的 TIMESTAMP 类型存在 2038 年限制（因为底层是 32 位整数）。迁移时应优先使用 DATETIME 类型来避免此问题。TiDB 默认使用 DATETIME，不受此限制。
LOB 类型
DB2 的 CLOB/BLOB 在使用上有较多限制（比如不能作为主键、不能用于某些函数的参数）。MySQL 的 TEXT/BLOB 限制不同，需要确认目标数据库对大字段的支持范围。
SQL 语法细节
FETCH FIRST vs LIMIT
DB2 使用 FETCH FIRST n ROWS ONLY 做分页，MySQL 用 LIMIT n。这个映射很简单，但如果代码中大量使用 DB2 的 OFFSET n ROWS FETCH FIRST m ROWS ONLY 语法，需要改为 LIMIT m OFFSET n。
VALUES 子句
DB2 允许 VALUES (1, 'a') 作为独立语句返回一行结果，MySQL 不支持这种用法。如果存储过程或应用代码中使用了这种写法，需要改为 SELECT 1, 'a'。
空字符串 vs NULL
DB2 默认把空字符串当作 NULL 处理（'' = NULL）。MySQL 区分空字符串和 NULL。如果业务逻辑依赖「空字符串等于 NULL」的行为，迁移后可能出现数据不一致。
IDENTITY 列
DB2 的 IDENTITY 列对应 MySQL 的 AUTO_INCREMENT，但行为细节不同：
递归 CTE
DB2 支持递归 CTE（Common Table Expression），大部分现代数据库也支持。但递归深度限制不同，DB2 默认没有深度限制，部分数据库有最大递归深度设置。
实际建议
TiDB 在 DB2 LUW 迁移中的对应能力
TiDB 兼容 MySQL 协议，上述数据类型和 SQL 语法差异本质上是 DB2 到 MySQL 的差异，TiDB 的行为与 MySQL 一致。TiDB 默认使用 DATETIME 而非 TIMESTAMP，不受 2038 年限制。建议在迁移前用语法扫描工具对 DB2 的 DDL 和 SQL 做一次全量扫描，生成数据类型映射表，再结合小规模数据导入验证实际兼容性。
如果你正在评估 DB2 LUW 迁移，建议先做一份数据类型映射表和 SQL 语法扫描清单，确认高风险项后再启动正式迁移。