ERROR 1833 是因字段被外键、主键等约束引用导致修改失败，解决需先查删外键（如SELECT CONSTRAINT_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE）、再DROP PRIMARY KEY（若为主键）、修改后重建约束与索引，并同步更新ORM及缓存逻辑。
报错 ERROR 1833：外键或主键约束拦路
最常见的报错是 error 1833 (hy000): cannot change column 'xxx': used in a foreign key constraint。这不是类型转换本身的问题，而是 mysql 8.0+ 对元数据变更更严格了——只要该字段被外键、主键、唯一索引或生成列引用，modify column 就直接拒绝执行。
解决路径不是“绕过”，而是拆解依赖：
- 先查外键：
SELECT CONSTRAINT_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE TABLE_NAME='t' AND COLUMN_NAME='id' - 再删外键：
ALTER TABLE t DROP FOREIGN KEY fk_name - 主键字段需先
DROP PRIMARY KEY（若无自增，可后续加回） - 改完类型后，记得手动重建外键和索引，否则关联查询会失效
phpMyAdmin 界面点“保存”却静默失败？默认值和字符集没填对
phpMyAdmin 的图形化修改本质是拼 SQL，但它不会自动补全关键细节。你点保存时，它可能悄悄执行了不带 CHARACTER SET 和 DEFAULT 的语句，导致报错或数据异常。
必须手动检查并补全三项：
-
DEFAULT值必须加单引号，比如DEFAULT '0'；写成DEFAULT 0会触发Invalid default value for 'xxx' - 必须显式指定
CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci，否则新列可能沿用数据库旧默认（如latin1），存中文就乱码 - 原列若有
NOT NULL，新语句里也得带上，否则字段会变成允许NULL，破坏业务逻辑
改完发现值全变“0”或空？不是丢数据，是 phpMyAdmin 展示错位
这通常不是真实数据丢失，而是 phpMyAdmin 缓存了旧结构，或底层未真正执行类型变更，只改了元数据。整数字段强行标成 VARCHAR 后，它仍按二进制读取，显示为 ASCII 字符（比如 20 → HEX 14 → 显示为空或乱码）。
立即学习“PHP免费学习笔记（深入）”；
验证真实状态的最快方式：
- 执行
SELECT age, LENGTH(age), HEX(age) FROM test_table LIMIT 1 - 如果
LENGTH是 0 或HEX是空，说明真丢了；如果LENGTH是 1 且HEX是30（即字符'0'），说明只是展示异常 - 点 phpMyAdmin 右上角“刷新”按钮，或清浏览器缓存重进
INT 转 VARCHAR 后应用层炸了？ORM 类型映射没同步
数据库改完了，代码不改照样报错。Django 的 IntegerField 拿到字符串会抛 ValueError: invalid literal for int()；MyBatis 的 resultMap 若还按 int 解析，就会把 '123' 当数字强转失败。
迁移必须连动三处：
- 数据库字段类型（已做）
- ORM 模型定义（如 Django 的
models.CharField、Laravel 的string()） - 缓存序列化逻辑（如 Redis 存的是 JSON，字段类型变了，反序列化可能失败）
最危险的是漏掉缓存——旧缓存里还是整数，新代码读出来是字符串，类型混用在运行时才暴露，很难覆盖测试到。
