Navicat直接修改字段类型或长度时不报错不预警，易致隐性数据丢失；必须手动检查数据分布、禁用自动保存、用DDL验证后再执行ALTER，并显式指定字符集与排序规则。
直接修改字段类型或长度时，navicat 默认会尝试隐式转换或截断，不报错也不预警——这是数据丢失最隐蔽的源头。 它不会阻止你把 varchar(255) 改成 varchar(10)，哪怕已有 200 条记录的值超长；也不会提醒你把 int 改成 tinyint 后，大于 127 的数字会被强制转为 127 或溢出归零。
修改字段前必须手动检查现有数据分布
Navicat 的「编辑字段」界面只显示定义，不显示真实数据。你得自己查：
- 执行
SELECT MAX(LENGTH(字段名)) FROM 表名;确认当前最大长度，再决定新长度是否安全 - 对数值型字段，跑
SELECT MIN(字段名), MAX(字段名) FROM 表名;，比对目标类型取值范围（比如TINYINT是 -128~127） - 对日期/时间字段，用
SELECT COUNT(*) FROM 表名 WHERE 字段名 NOT REGEXP '^[0-9]{4}-[0-9]{2}-[0-9]{2}.*$';排查非法格式残留
禁用 Navicat 的“自动保存更改”并改用手动 SQL
Navicat 表设计界面勾选「保存」后默认直接执行 ALTER TABLE ... MODIFY，跳过确认、不可撤回。更安全的做法是：
- 在表上右键 → 【对象信息】→ 切换到【DDL】页签，复制生成的原始
ALTER语句 - 粘贴到新查询窗口，在执行前手动加
SELECT验证：比如改长度前先SELECT 字段名 FROM 表名 WHERE LENGTH(字段名) > 新长度; - 确认无结果后再执行
ALTER；如有，先清理或迁移数据，再改结构
修改字段时务必显式指定 USING 和 COLLATE（尤其字符型）
Navicat 点击保存时若未显式声明字符集和排序规则，MySQL 可能按库默认值处理，导致中文乱码或比较异常：
- 避免直接点「确定」，改用 SQL：
ALTER TABLE 表名 MODIFY 字段名 VARCHAR(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 如果原字段含索引，
MODIFY会重建索引；但若只改COLLATE，建议用ALTER TABLE 表名 ALTER COLUMN 字段名 SET COLLATE utf8mb4_unicode_ci;（MySQL 8.0.30+）减少锁表时间 - 对大表，这类操作可能阻塞写入，务必避开业务高峰
真正危险的不是 Navicat 功能弱，而是它太“顺滑”——一个回车就提交 DDL，连事务都包不住。最常被忽略的一点是：ALTER TABLE ... MODIFY 在 MySQL 中属于“原地修改”，失败时已部分生效，无法靠 ROLLBACK 拉回来。所以每次改字段，本质是一次微型上线操作，得有验证、有回退、有监控。
