把MySQL数据库迁移到DB2是很多企业系统替换或升级时不可避免的工作。迁移任务除了数据搬运本身，最容易被低估的就是数据类型的映射。两者虽然都支持关系模型，但在底层实现上差异很大：MySQL允许无符号整数、存在多种文本类型（TINYTEXT、MEDIUMTEXT、LONGTEXT），而DB2的数值类型默认带符号、文本类型更统一。如果不提前规划映射规则，迁移后很可能出现插入失败、精度丢失、索引失效等问题。因此，在动手迁移之前先把类型映射搞清楚，能省去后续大量排错时间。

数值类型的映射差异与转换陷阱

MySQL中的整数类型分为TINYINT、SMALLINT、MEDIUMINT、INT、BIGINT，而且默认支持无符号（UNSIGNED）属性，这使得一个TINYINT UNSIGNED可以存储0到255。DB2的整数类型只有SMALLINT、INTEGER（或INT）、BIGINT，且全部为有符号，不存在无符号整数。因此直接照搬MySQL类型定义到DB2时，TINYINT UNSIGNED会变成SMALLINT，MEDIUMINT会变成INTEGER，而无符号BIGINT则会溢出或需要转换为DECIMAL(20,0)。很多迁移失败就是因为忽略了无符号属性，导致数据插入时超出范围报错。

在实际映射时，建议遵循“向上兼容”原则：MySQL的TINYINT不管是否有符号，都映射为DB2的SMALLINT；SMALLINT映射为SMALLINT；MEDIUMINT映射为INTEGER；INT映射为INTEGER；BIGINT映射为BIGINT。如果原始列是无符号且数据范围可能超过DB2对应有符号类型的上限，则需要使用更大的类型，例如无符号INT超过2147483647时，应使用BIGINT。对于精度要求极高的场景，可以使用DECIMAL(p,s)来替代整数类型，但要注意DECIMAL的存储开销远大于整数，且索引效率较低。

浮点数方面，MySQL的FLOAT和DOUBLE分别对应DB2的REAL和DOUBLE（或FLOAT，DB2中FLOAT默认为DOUBLE精度）。但MySQL的FLOAT(M,D)中M和D是显示宽度和小数位数，实际上存储仍是近似值；DB2的REAL和DOUBLE也遵循IEEE 754标准。迁移时可以直接映射，但需要注意：如果应用依赖MySQL的浮点舍入行为，在DB2上可能存在微小差异。对于需要精确计算的场景，建议在迁移时就把FLOAT/DOUBLE改为DECIMAL，避免后续出现金额计算错误。

下面是一个数值类型映射及建表语句的对比示例，帮助理解差异：

-- MySQL 原始表
CREATE TABLE orders (
    id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    quantity TINYINT UNSIGNED NOT NULL,
    amount DECIMAL(10,2) NOT NULL,
    rate FLOAT DEFAULT 0.0
);
-- 迁移到 DB2 后的表
CREATE TABLE orders (
    id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    quantity SMALLINT NOT NULL CHECK (quantity >= 0),
    amount DECIMAL(10,2) NOT NULL,
    rate DOUBLE DEFAULT 0.0
);

注意DB2的自增列使用IDENTITY语法，且通常需要BIGINT来容纳可能的大量行。同时，DB2的CHECK约束可以模拟无符号限制，但需要额外添加。如果MySQL原表使用了ZEROFILL属性，则DB2中建议使用VARCHAR或CHAR搭配LPAD处理，且该属性在标准SQL中并不存在。

字符与二进制类型的映射策略

MySQL的字符类型非常丰富：CHAR、VARCHAR、TINYTEXT、TEXT、MEDIUMTEXT、LONGTEXT，以及BINARY、VARBINARY、BLOB系列。DB2的字符类型相对统一，主要有CHAR、VARCHAR、CLOB（字符大对象），以及GRAPHIC/VARGRAPHIC（用于双字节字符，但较少直接使用）、BINARY、VARBINARY、BLOB。映射时需要重点关注长度限制和字符集支持。

对于定长字符串CHAR(n)，MySQL的n代表字符数，最大255字节（受字符集影响）；DB2的CHAR(n)中n代表字节数还是字符数取决于数据库代码页和字符串单位。在DB2中默认情况下，CHAR和VARCHAR的长度单位由数据库配置决定，通常为字节（但可通过设置STRING_UNITS=CODEUNITS32改为字符）。为了安全，迁移时建议将MySQL的CHAR(n)和VARCHAR(n)直接映射为DB2的CHAR(n OCTETS)或VARCHAR(n OCTETS)，并把n设置为原字节长度。例如UTF-8字符集下MySQL的VARCHAR(255)可能存储255个字符，但字节长度可能达到765，此时DB2需要VARCHAR(765)或更大的值，否则可能出现截断。

MySQL的TEXT系列在DB2中对应CLOB，但需要注意CLOB不能直接用于普通索引（DB2 10.5以上支持对CLOB创建基于表达式索引，但性能较差）。如果MySQL表中有对TEXT列进行全文索引或普通索引的需求，迁移到DB2时需要改为其他方案，比如使用VARCHAR(最大长度)或创建辅助表。而BLOB系列则对应DB2的BLOB，两者行为类似，但DB2的BLOB默认最大2GB，MySQL的LONGBLOB最大4GB，迁移前需要检查实际数据大小。

以下是一个字符类型映射的示例，展示如何处理UTF-8字符集和长度换算：

-- MySQL
CREATE TABLE articles (
    title VARCHAR(200) CHARACTER SET utf8mb4,
    content LONGTEXT,
    cover_image LONGBLOB
);
-- DB2 (假设数据库默认代码集为UTF-8)
CREATE TABLE articles (
    title VARCHAR(800 OCTETS),  -- utf8mb4下每个字符最多4字节
    content CLOB(2G),
    cover_image BLOB(2G)
);

对于二进制字符串，MySQL的BINARY(n)和VARBINARY(n)分别对应DB2的BINARY(n)和VARBINARY(n)，但DB2中这些类型长度单位是字节，无需额外转换。需要注意MySQL的BIT类型存储位串，而DB2没有直接的BIT类型，通常使用SMALLINT或CHAR(1)结合CHECK来替代，或者用BINARY(n)加应用程序解析。

日期时间类型的精度范围与隐式转换

MySQL的日期时间类型包括DATE、TIME、DATETIME、TIMESTAMP、YEAR，其中DATETIME范围从1000-01-01到9999-12-31，TIMESTAMP范围从1970-01-01 00:00:01 UTC到2038-01-19 03:14:07 UTC（受时区影响）。DB2提供DATE、TIME、TIMESTAMP三种类型，其中TIMESTAMP支持小数秒精度，范围从0001-01-01到9999-12-31。YEAR类型在DB2中不存在，需要映射为SMALLINT或CHAR(4)并加约束。

映射时，MySQL的DATE对应DB2 DATE，TIME对应DB2 TIME，DATETIME对应DB2 TIMESTAMP(0)或TIMESTAMP(p)（p表示小数秒精度，MySQL的DATETIME(3)可映射为TIMESTAMP(3)）。而MySQL的TIMESTAMP需要特别注意：它存储的是UTC时间，读取时按会话时区转换。DB2的TIMESTAMP不带时区，如果不做处理，迁移后同一时间的显示值可能因应用连接会话不同而变化。建议在迁移时把MySQL的TIMESTAMP统一转换为DATETIME型数据，并在应用层处理时区，或者直接将MySQL的TIMESTAMP映射为DB2的TIMESTAMP并设定应用统一使用UTC。

此外，MySQL允许零日期（如0000-00-00）和部分非法日期，DB2默认会拒绝这些值。迁移前需要清理数据或设置DB2的兼容性参数。MySQL中还存在ON UPDATE CURRENT_TIMESTAMP子句，DB2没有直接对应语法，需要用触发器或生成列来模拟。下面是一个日期类型的迁移示例：

-- MySQL
CREATE TABLE events (
    event_date DATE,
    event_time TIME,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at DATETIME
);
-- DB2 (部分模拟)
CREATE TABLE events (
    event_date DATE,
    event_time TIME,
    created_at TIMESTAMP DEFAULT CURRENT TIMESTAMP,
    updated_at TIMESTAMP
);
-- 需要为 updated_at 创建触发器实现自动更新
CREATE TRIGGER events_bu
BEFORE UPDATE ON events
REFERENCING NEW AS N
FOR EACH ROW
SET N.updated_at = CURRENT TIMESTAMP;

YEAR类型映射也容易遗漏：MySQL的YEAR存储1901到2155的年份，通常用于统计。迁移到DB2时可使用SMALLINT并添加CHECK约束，或者直接使用CHAR(4)存储四位年份。建议统一使用SMALLINT以避免字符串比较性能问题。

迁移后的验证与自动化映射建议

完成表结构迁移后，必须进行数据完整性验证。可以通过对比两边表的行数、抽样核对数值、检查字符型数据是否被截断、比较日期范围等方法来确认映射是否成功。如果迁移工具支持，可以使用DB2的IMPORT或LOAD命令加载数据，并开启警告捕获，检查是否有数据被截断或转换异常。例如在DB2中，LOAD命令会生成警告文件，里面记录了所有被截断或转换失败的行，通过分析这些警告可以快速定位映射问题。

自动化建表映射可以借助一些开源工具或自研脚本。基本思路是读取MySQL的information_schema，解析字段类型和属性，然后按照预设规则生成DB2的DDL。规则表可以设计为键值对：例如MySQL类型字符串"int unsigned"对应DB2类型"BIGINT"，"varchar(255)"对应"VARCHAR(255 OCTETS)"等。脚本还需要处理自增列转换（改为GENERATED ALWAYS AS IDENTITY）、默认值替换（如MySQL的CURRENT_TIMESTAMP改为CURRENT TIMESTAMP）、索引和约束的转换。

下面是一个简单的Python伪代码片段，展示如何利用映射字典生成DB2类型：

mysql_to_db2 = {
    'tinyint': 'SMALLINT',
    'smallint': 'SMALLINT',
    'mediumint': 'INTEGER',
    'int': 'INTEGER',
    'bigint': 'BIGINT',
    'float': 'DOUBLE',
    'double': 'DOUBLE',
    'decimal': 'DECIMAL',
    'char': 'CHAR',
    'varchar': 'VARCHAR',
    'text': 'CLOB',
    'blob': 'BLOB',
    'datetime': 'TIMESTAMP',
    'timestamp': 'TIMESTAMP',
}
def map_type(mysql_col):
    base_type = mysql_col.lower().split('(')[0].split(' ')[0]
    if base_type in mysql_to_db2:
        return mysql_to_db2[base_type]
    else:
        return 'VARCHAR(4000)'  # 兜底类型

最后强调一点：数据类型映射不是一个静态的对照表，它需要结合业务实际、数据分布和性能要求动态调整。例如一个存储状态的TINYINT列，如果业务上只有0和1两个值，映射到DB2时完全可以使用CHAR(1)或SMALLINT，但CHAR(1)可能更节约空间且可读性强；而一个频繁参与数值计算的INT列，则必须保留为BIGINT或INTEGER，不能简化。因此，在制定映射规范时，建议由开发、DBA和业务人员共同评审，并在测试环境用真实数据充分验证后再上线。