ALTER TABLE 修改字段类型失败主因是约束依赖而非类型不兼容，须先删外键、主键等依赖再重建，并同步更新应用层代码与缓存。
ALTER TABLE 修改字段类型时 MySQL 报错 ERROR 1833
直接执行 alter table t modify column id varchar(32) 可能失败，尤其当字段是主键、有外键、或被索引引用时。mysql 8.0+ 对隐式类型转换更严格，error 1833 (hy000): cannot change column 'id': used in a foreign key constraint 是最常见拦路虎。
根本原因不是类型本身不兼容，而是约束依赖阻断了修改路径。绕过它不是靠“强转”，而是先解除依赖再重建。
- 先删外键：查
SELECT CONSTRAINT_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE TABLE_NAME='t' AND COLUMN_NAME='id'，再用ALTER TABLE t DROP FOREIGN KEY xxx - 主键/唯一索引字段不能直接改类型：必须先
DROP PRIMARY KEY（若无自增，可先MODIFY再加回） - 有默认值或非空约束的字段，
MODIFY时需显式重申NOT NULL DEFAULT '...'，否则会被清空
VARCHAR 转 INT：数据内容决定成败，不是语法能兜底
ALTER TABLE t MODIFY COLUMN code INT 看似简单，但只要 code 里存在 'abc'、'12a'、空字符串或超范围值（如 '2147483648'），MySQL 就会静默截断或转成 0——而且不会报错，除非你开了严格模式（STRICT_TRANS_TABLES）。
真正安全的做法是分三步验证：
- 查脏数据：
SELECT code FROM t WHERE code REGEXP '^[0-9]+$' = 0 OR code = '' OR CAST(code AS SIGNED) > 2147483647 - 清理或归档异常值（比如导出为
code_bak字段存原始字符串） - 确认无误后，再执行
MODIFY，并立刻加NOT NULL和CHECK (code > 0)防后续污染
INT 转 VARCHAR：长度设太小反而引发隐式截断
把 user_id INT 改成 VARCHAR(4) 很危险——因为最大 INT 是 2147483647（10 位），VARCHAR(4) 只能存 "1234"。一旦插入值超过长度，MySQL 在非严格模式下会静默截断，比如 12345 存成 '1234'，且不报错。
合理长度建议：
- 有符号
INT→ 至少VARCHAR(11)（负号 + 10 位数字） - 无符号
INT UNSIGNED→VARCHAR(10) - 如果字段将来可能存 UUID 或混合前缀（如
'U12345'），别硬套数字长度，按业务最大可能设，留余量
迁移过程中的应用层风险：ORM 和缓存没同步就炸了
数据库改完，代码不改照样出问题。Django 的 IntegerField 映射到新 VARCHAR 字段，取值时可能报 ValueError: invalid literal for int()；MyBatis 若没更新 resultMap 类型，会把字符串当数字解析失败。
缓存更隐蔽：Redis 里存的旧结构（如 {'id': 123}）和新字段类型不匹配，反序列化时可能丢字段或类型错误。
- 上线前必须检查所有读写该字段的 DAO 层、DTO、JSON 序列化配置
- 缓存 key 设计带版本号（如
user:v2:123），避免新老逻辑混用 - 灰度发布时，先开只读新字段，用双写比对数据一致性，再切写入
类型转换看着是 DBA 一条命令的事，实际卡点永远在数据洁不洁、代码跟不跟、缓存清不清——这三个地方漏一个，半夜告警就是它。
