MySQL如何实现跨异构数据库迁移_数据类型映射与字段转换-mysql教程-PHP中文网

mysql的datetime映射postgresql的timestamp without time zone，timestamp映射timestamp with time zone；若源为utc，目标用timestamptz并加at time zone 'utc'；应用层需适配时区逻辑。

mysql如何实现跨异构数据库迁移_数据类型映射与字段转换

MySQL 到 PostgreSQL 迁移时 `datetime` 和 `timestamp` 怎么映射？

MySQL 的 datetime 默认不带时区，timestamp 却隐式依赖系统时区且自动转换；PostgreSQL 的 timestamp without time zone 表面像前者，但语义更接近 MySQL 的 datetime，而 timestamp with time zone 才真正做时区归一化。直接按字段名一对一映射会出问题。

如果源数据全是 UTC 时间，目标用 timestamp with time zone 最稳妥，导入时加 AT TIME ZONE 'UTC' 强制解释
若业务逻辑依赖 MySQL 的“本地时间存储+本地时区读取”行为（比如日志时间按服务器所在时区写入），迁到 PostgreSQL 后必须统一改写应用层，不能靠数据库自动补救
timestamp 字段在 MySQL 5.6+ 支持微秒，PostgreSQL 默认也支持，但迁移工具如 pgloader 需显式开启 with truncate 和 with data 才保留精度，否则默认截断到秒

Oracle `NUMBER(10,2)` 导入 MySQL 后精度丢失怎么办？

Oracle 的 NUMBER 是精确十进制类型，MySQL 的 DECIMAL 虽然也是定点数，但声明方式不同：NUMBER(10,2) 对应的是 DECIMAL(10,2)，不是 FLOAT 或 DOUBLE。很多迁移脚本误用浮点类型，导致小数四舍五入或科学计数法显示。

检查导出 SQL 是否含 CAST(... AS FLOAT) 类型转换，这是精度丢失主因
使用 mysqldump --compatible=oracle 并不真正兼容 Oracle 类型，它只改语法糖，NUMBER 仍被转成 DOUBLE，得手动替换正则：NUMBER((\d+),(\d+)) → DECIMAL($1,$2)
MySQL 8.0+ 支持 DECIMAL 最大 65 位精度，但客户端（如 Python 的 mysql-connector-python）默认把 DECIMAL 当 float 返回，需显式设 decimal_values=True 参数

SQL Server `uniqueidentifier` 字段迁到 MySQL 后查不到记录？

SQL Server 的 uniqueidentifier 是 16 字节二进制 UUID，常以 'A0EEBC99-9C0B-4EF8-BB6D-6BB9BD380A11' 格式存储；MySQL 原生不识别这种格式，若直接当字符串导入到 VARCHAR(36)，虽然能存，但排序、索引效率差，且和 MySQL 的 UUID() 函数不互通。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

更优做法是转成 BINARY(16)：用 UNHEX(REPLACE(uuid_str, '-', '')) 入库，查询时用 HEX(uuid_col) 反查，或用 UUID_TO_BIN()（MySQL 8.0.1+）
注意大小端：SQL Server 默认小端序生成 UUID，MySQL 的 UUID_TO_BIN() 默认大端序，要加第二个参数 1： UUID_TO_BIN('A0EEBC99-9C0B-4EF8-BB6D-6BB9BD380A11', 1)
如果已有数据在 VARCHAR(36) 里，别用 LIKE 模糊查，REPLACE(col, '-', '') = UNHEX(...) 无法走索引，得重建字段并加函数索引

迁移后 `TEXT` 字段内容莫名被截断或乱码？

本质是字符集与排序规则没对齐。MySQL 的 utf8mb4 是真 UTF-8，而旧版迁移工具（如某些版本的 mysqldump 或 Navicat）默认用 utf8（即 utf8mb3），遇到 emoji 或生僻汉字就丢字节；PostgreSQL 默认 UTF8 没问题，但连接层可能强制 client_encoding 为 SQL_ASCII。

导出前确认 MySQL 服务端字符集：SHOW VARIABLES LIKE 'character_set%';，重点看 character_set_server 和 collation_server
导入命令必须带 --default-character-set=utf8mb4，且连接字符串加 ?charset=utf8mb4
PostgreSQL 侧检查 SHOW client_encoding;，不是 UTF8 就执行 SET client_encoding = 'UTF8';
TEXT 类型本身无长度限制，但中间件（如 Django ORM）可能默认用 TextField 对应，若原始字段是 MEDIUMTEXT 且含超长内容，得确认 ORM 层没做隐式截断