直接在Navicat表设计界面修改字段类型（如VARCHAR转INT）会导致数据丢失，因MySQL强制转换失败时置为NULL或0；安全修改需满足类型兼容、无隐式转换风险、不触发重建表三前提。
修改字段类型时数据丢失的典型现象
直接在 navicat 的表设计界面双击字段改类型（比如把 varchar(50) 改成 int），点保存后弹出警告“此操作可能导致数据丢失”，点确定——结果整列值全变 null 或默认值。这不是 bug，是 mysql 的 alter table ... modify column 在类型不兼容时的强制截断/转换行为。
安全修改字段的三个前提条件
能否保留数据，取决于新旧类型是否兼容、是否有隐式转换风险、以及是否触发重建表。Navicat 默认用 ALTER TABLE，但不会帮你判断语义合理性：
- 字符型 → 字符型（如
VARCHAR(50)→VARCHAR(100)）：安全，仅扩展长度，数据原样保留 - 数字型 → 数字型（如
TINYINT→SMALLINT）：安全，范围扩大无损 - 字符型 → 数字型（如
VARCHAR→INT）：高危，MySQL 尝试字符串转数字，失败则置为0或NULL - 加
NOT NULL且字段含NULL值：会报错，必须先更新空值
Navicat 中真正保留数据的操作路径
别依赖“保存”按钮自动处理。手动控制 SQL 才可靠：
- 右键表 → 「设计表」→ 修改字段 → 不点保存，先点左上角「SQL」标签，看 Navicat 生成的语句是不是
MODIFY COLUMN或CHANGE COLUMN - 如果目标是扩长度或加注释，直接执行该语句没问题；如果是类型变更，删掉自动生成的语句，手写带数据迁移逻辑的 SQL
- 例如把
name VARCHAR(50)改成full_name TEXT，应分两步：
— 新增临时字段：ALTER TABLE user ADD COLUMN full_name TEXT;
— 迁移数据：UPDATE user SET full_name = name;
— 删除旧字段：ALTER TABLE user DROP COLUMN name; - 对生产表，务必在测试库先跑通，再加
WHERE条件分批执行（避免锁表太久）
容易被忽略的底层细节
Navicat 的「设计表」界面背后调用的是 MySQL 的在线 DDL（8.0+）或拷贝表（旧版本）。即使语句看起来简单，ALTER TABLE ... CHANGE COLUMN 在某些组合下仍会触发表重建——这意味着所有索引重建、外键校验重跑、MVCC 版本链重刷。大表操作前，一定要查 SHOW CREATE TABLE 确认存储引擎和当前行格式，别只盯着字段名改完就点保存。
