转换结果将在这里呈现 —— 点「示例」试试| 含义 | MySQL | PostgreSQL | SQLite | Oracle | SQL Server |
|---|
把 MySQL 的 `TINYINT(1)` 迁到 PostgreSQL，发现 PG 没有同名类型，直接映射成 `SMALLINT` 会导致 ORM 的布尔字段报错。这个工具把 MySQL、PostgreSQL、SQLite、Oracle 四套字段类型体系对齐，输入源库类型，自动给出目标库的最佳映射（含长度、精度、默认值差异）。映射规则参考各官方文档，不依赖第三方 API，数据不出浏览器。
周一凌晨要把一个跑了三年的 MySQL 订单库迁到 PostgreSQL。表里有个字段是 MySQL 的 `MEDIUMINT`，PG 不认识。DBA 小陈翻了两本手册，发现 PG 的 `INTEGER` 范围是 -2147483648 到 2147483647，而 MySQL 的 `MEDIUMINT` 范围是 -8388608 到 8388607。用本工具一查，`MEDIUMINT` 直接对应 PG 的 `INTEGER`，范围完全覆盖，不用改列定义，迁移脚本直接生成，省了半小时查文档和手动换算的时间。
后端团队用 SQLAlchemy 开发新模块，模型里定义了 `sqlalchemy.SmallInteger`，但生产库是 Oracle。Oracle 没有 `SMALLINT` 类型，只有 `NUMBER(38)`。开发组长老李拿不准 `SmallInteger` 在 Oracle 落地时会不会被映射成 `INTEGER` 导致空间浪费。用本工具一查，SQLAlchemy 的 `SmallInteger` 对应 Oracle 的 `NUMBER(5)`，直接写进迁移脚本里，避免了全表扫描时因类型不匹配触发的隐式转换。
独立开发者用 SQLite 做原型，表里有个 `REAL` 字段存经纬度。上线要切到 MySQL，MySQL 没有 `REAL` 类型，只有 `DOUBLE` 和 `FLOAT`。查了 MySQL 文档，`FLOAT` 是单精度 7 位有效数字，`DOUBLE` 是双精度 15 位。用本工具一对比，`REAL` 在 MySQL 里对应 `DOUBLE`，精度比 `FLOAT` 高两倍，但占 8 字节。如果存的是手机信号塔坐标（±0.1 度），`FLOAT` 就够了，能省一半存储。这个判断让原型库的存储开销从 200MB 降到 100MB。
数据中台要打通 Oracle 和 MySQL 两个数据源，做一张宽表。Oracle 的 `VARCHAR2(200)` 和 MySQL 的 `VARCHAR(200)` 看起来一样，但 `VARCHAR2` 以字节计，`VARCHAR` 以字符计。如果存中文，Oracle 一个汉字占 3 字节，200 字节只能存 66 个汉字，MySQL 200 字符能存 200 个汉字。用本工具一查，Oracle 的 `VARCHAR2(200)` 对应 MySQL 的 `VARCHAR(600)` 才能保证不截断。这个细节让联表查询的字段映射没出乱码，ETL 任务一次跑通。
新来的实习生设计了一张用户表，MySQL 里 `user_id` 用了 `BIGINT UNSIGNED`，`status` 用了 `TINYINT(1)`。架构师老张做评审，担心 `TINYINT(1)` 在 PG 里会被当作布尔类型。用本工具一查，MySQL 的 `TINYINT(1)` 对应 PG 的 `SMALLINT`，不是布尔。而 `BIGINT UNSIGNED` 在 PG 里没有无符号对应，只能用 `NUMERIC(20)` 或 `BIGINT` 并限制非负。这个发现让实习生改了字段定义，避免了未来迁移时数据溢出。
| 输入 | 输出 | 说明 |
|---|---|---|
| VARCHAR(255) | MySQL: VARCHAR(255) → PG: VARCHAR(255) → SQLite: TEXT → Oracle: VARCHAR2(255) | 常规：最常用的变长字符串类型，验证各数据库间基本映射正确性 |
| INT UNSIGNED | MySQL: INT UNSIGNED → PG: INTEGER (无符号被丢弃，范围变为 -2147483648~2147483647) → SQLite: INTEGER → Oracle: NUMBER(10) | 边界：MySQL 无符号整数在 PG 中无对应，工具需说明精度丢失风险 |
| TINYINT(1) | MySQL: TINYINT(1) → PG: SMALLINT → SQLite: INTEGER → Oracle: NUMBER(3) | 易错：MySQL 中 TINYINT(1) 常被误认为布尔值，实际映射为 SMALLINT，非 BOOLEAN |
| GEOMETRY | MySQL: GEOMETRY → PG: GEOMETRY (需 PostGIS 扩展) → SQLite: BLOB (无原生空间类型) → Oracle: SDO_GEOMETRY (需 Spatial 扩展) | 边界：空间数据类型在 SQLite 中无原生支持，工具标注了扩展依赖 |
| DECIMAL(10,2) | MySQL: DECIMAL(10,2) → PG: NUMERIC(10,2) → SQLite: REAL (精度丢失为浮点) → Oracle: NUMBER(10,2) | 易错：SQLite 无定点数类型，DECIMAL 会被降级为 REAL，导致舍入误差 |
| YEAR | MySQL: YEAR → PG: SMALLINT → SQLite: INTEGER → Oracle: NUMBER(4) | 常规：MySQL 专用日期类型，映射为数值类型，验证非标准类型的处理 |
| SET('a','b','c') | MySQL: SET('a','b','c') → PG: TEXT (需应用层校验) → SQLite: TEXT → Oracle: VARCHAR2(3) | 边界：MySQL SET 枚举集合类型，PG/Oracle 无原生对应，工具输出 TEXT 并提示校验缺失 |
| BIGINT UNSIGNED | MySQL: BIGINT UNSIGNED → PG: NUMERIC(20) (超出 INT8 范围) → SQLite: INTEGER (可能溢出) → Oracle: NUMBER(20) | 易错：BIGINT UNSIGNED 最大值 18446744073709551615 超出 PG INT8，工具自动升级为 NUMERIC |
1.MySQL 的 TINYINT(1) 误转成 PG 的 BOOLEAN
MySQL 表有 TINYINT(1) 字段，直接转成 PostgreSQL 的 BOOLEANTINYINT(1) → SMALLINT（或保留为 INTEGER）MySQL 中 TINYINT(1) 仅表示显示宽度为 1，仍是整数类型；PG 的 BOOLEAN 语义不同，转换后查询条件需重写，且数据范围不兼容。
2.Oracle 的 NUMBER 未指定精度，转成 PG 后丢失小数
Oracle 字段 NUMBER → PostgreSQL 字段 INTEGERNUMBER → NUMERIC（或 DECIMAL）Oracle 的 NUMBER 默认可存储小数，INTEGER 只接受整数，直接转换会导致数据截断或插入失败，应保留为 NUMERIC 类型。
3.SQLite 的 TEXT 直接转成 MySQL 的 VARCHAR 忽略长度
SQLite 字段 TEXT → MySQL 字段 VARCHARSQLite 的 TEXT → MySQL 的 TEXT 或 LONGTEXTSQLite 的 TEXT 无长度限制，而 MySQL 的 VARCHAR 有 65535 字节上限；直接转换可能导致长文本截断，应使用 TEXT 系列类型。
4.MySQL 的 DATETIME 转 Oracle 时误用 DATE
MySQL 字段 DATETIME → Oracle 字段 DATEDATETIME → TIMESTAMPOracle 的 DATE 类型包含时分秒但精度为秒，而 MySQL 的 DATETIME 支持微秒（6 位小数），转 DATE 会丢失毫秒部分，应使用 TIMESTAMP。
5.PG 的 SERIAL 转 MySQL 时直接写 INT
PostgreSQL 字段 SERIAL → MySQL 字段 INTSERIAL → INT AUTO_INCREMENTSERIAL 是 PG 的自动递增整数语法，MySQL 使用 AUTO_INCREMENT 实现相同功能；仅转类型不转自增属性会导致插入时需手动指定 ID。
6.Oracle 的 VARCHAR2 转 SQLite 时忽略字符集差异
Oracle 字段 VARCHAR2(100) → SQLite 字段 VARCHAR(100)VARCHAR2(100) → TEXT（或 VARCHAR(100) 但注意字节数）Oracle 的 VARCHAR2 按字节计数（如 100 字节），SQLite 的 VARCHAR 按字符计数；中文字符在 Oracle 中可能只存 33 个，直接转换会溢出。
7.MySQL 的 ENUM 转 PG 时直接写 TEXT
MySQL 字段 ENUM('a','b','c') → PostgreSQL 字段 TEXTENUM('a','b','c') → 自定义类型 CREATE TYPE my_enum AS ENUM('a','b','c')ENUM 在 MySQL 中限制值范围，转成 TEXT 会失去约束，允许插入非法值；PG 支持自定义 ENUM 类型，应创建同名枚举以保持业务规则。
8.PG 的 JSONB 转 MySQL 时误用 JSON
PostgreSQL 字段 JSONB → MySQL 字段 JSONJSONB → JSON（但注意功能差异）MySQL 8.0+ 的 JSON 类型与 PG 的 JSONB 存储格式不同，MySQL 不支持 @> 等部分 JSONB 操作符，转换后需手动改写查询逻辑。
type_map = {source_db: {target_db: {source_type: target_type}}}
source_db源数据库类型，如 MySQLtarget_db目标数据库类型，如 PostgreSQLsource_type源字段类型，如 VARCHAR(255)target_type映射后的目标字段类型MySQL 的 VARCHAR(255) 转 PostgreSQL：查映射表得 TEXT（PG 无 VARCHAR 长度限制）；转 SQLite 得 TEXT（SQLite 统一用 TEXT）；转 Oracle 得 VARCHAR2(255)。推导：映射表基于各数据库官方类型兼容性定义，非简单字符串替换。
不会自动变成布尔值。MySQL 的 tinyint(1) 本质是整数，PostgreSQL 有独立的 boolean 类型，但本工具按类型族映射：tinyint(1) 映射为 PostgreSQL 的 smallint（2 字节整数）。如果原本把 tinyint(1) 当布尔用（0/1），迁移后需要在应用层或手动改字段为 boolean。工具只做类型转换，不推断语义。
VARCHAR2 在 Oracle 中最大 4000 字节，MySQL 的 VARCHAR 最大 65535 字节，所以直接映射为 MySQL 的 VARCHAR，长度保留原值。但如果 Oracle 字段定义超过 4000（实际存的是 CLOB 场景），本工具会提示长度超限，建议手动改为 TEXT。工具输出时会标注原长度和推荐最大长度。
SQLite 的日期时间通常存为 TEXT（ISO 格式）或 INTEGER（Unix 时间戳）。本工具检测到字段名含 date/time/timestamp 且类型为 TEXT 时，映射为 MySQL 的 DATETIME；若为 INTEGER 则映射为 TIMESTAMP。如果字段名不明确，默认保留原类型（TEXT/INTEGER），建议迁移后手动验证。
SERIAL 是 PostgreSQL 的语法糖，本质是 INTEGER 加默认序列。本工具只转换字段类型，不生成表约束（如 AUTO_INCREMENT、DEFAULT 序列）。因此输出为 INT。迁移时需手动加上 AUTO_INCREMENT 属性。若使用完整 DDL 转换（本工具当前仅处理字段类型），建议结合其他工具处理约束。
能，但映射规则不同。PostgreSQL 原生支持 ENUM，本工具直接映射为 PG 的 ENUM 类型。Oracle 和 SQLite 不支持 ENUM，工具会转为 VARCHAR，并备注原枚举值列表，迁移后需手动添加 CHECK 约束。工具输出结果中会显示原 ENUM 的定义值（如 'small','medium','large'），方便后续处理。
完全本地运行。工具采用纯前端实现（FE），所有类型映射逻辑在浏览器中执行，输入的表结构数据不会离开本地设备。无需担心数据泄露，适合处理包含敏感字段名的生产库表结构。刷新页面后数据自动清除。
映射为 Oracle 的 NUMBER(10,2)。Oracle 没有独立的 DECIMAL 类型，NUMBER 完全等效。精度不会丢失，因为 NUMBER 可精确存储定点数。本工具保留原精度和小数位，输出结果直接显示 NUMBER(10,2)。如果原 DECIMAL 未指定精度（如 DECIMAL），则映射为 NUMBER（无精度限制）。
MySQL 从 5.7 起支持 JSON 类型，但 JSONB 是 PostgreSQL 的二进制 JSON 格式，功能更丰富（如索引、GIN 索引）。本工具映射为 MySQL 的 JSON 类型。需要注意：MySQL 的 JSON 列不能有默认值，且某些 JSON 函数名称不同（如 -> 操作符）。迁移后建议检查涉及 JSON 操作的查询语句。
能。SQLite 没有独立的 CLOB 类型，本工具映射为 TEXT。SQLite 的 TEXT 最大支持 2^31-1 字节（约 2GB），远超 Oracle CLOB 的 4GB 限制（实际受块大小影响）。但需注意：SQLite 的 TEXT 存储为 UTF-8 编码，若原 CLOB 含大量非 ASCII 字符，迁移后字节数可能增加。工具会提示原长度和 SQLite 限制。
MySQL 中 TIMESTAMP 受时区影响（存储 UTC，显示转本地），范围 1970-2038；DATETIME 不受时区影响，范围 1000-9999。转 PostgreSQL 时：TIMESTAMP 映射为 TIMESTAMP WITH TIME ZONE，DATETIME 映射为 TIMESTAMP WITHOUT TIME ZONE。如果原表使用 TIMESTAMP 且含 2038 年后的数据，迁移后需确认范围。工具输出时会在类型旁标注时区属性。
隐私保证所有计算与处理均在你的浏览器本地完成，输入数据不会上传服务器，也不会保存或共享。