MySQL严格模式下ALTER COLUMN缩容会因数据超长报“Data truncated”错误，需先查超长行、确认截断策略，再用三步法安全操作，JSON字段还需额外验证语法合法性。
ALTER COLUMN 遇到 Data truncated for column 错误
mysql 严格模式下，alter table ... modify column 或 alter table ... change column 改字段类型时，如果原数据无法无损适配新类型（比如把 varchar(255) 缩成 varchar(50)，而某条记录值长度是 120），就会直接报错：data truncated for column 'xxx' at row n。这不是警告，是中断性错误。
关键不是“能不能改”，而是“MySQL 拒绝做有损转换”——它不帮你截断、不静默丢数据，这是保护机制。
- 先查出哪些行会超长：
SELECT id, LENGTH(column_name) AS len FROM table_name WHERE LENGTH(column_name) > 50;
- 确认业务是否允许截断：如果允许，得手动清理或用
UPDATE截断后再改；如果不允许，必须扩容量或改逻辑 - 临时关严格模式风险极高：仅限开发环境且确认数据可丢，执行前加
SET sql_mode = '';，改完立刻恢复
strict_trans_tables 和 strict_all_tables 的区别
MySQL 严格模式其实有两个关键开关：STRICT_TRANS_TABLES 和 STRICT_ALL_TABLES。它们对 ALTER COLUMN 的影响不同。
STRICT_TRANS_TABLES 只对事务表（InnoDB）启用严格校验；STRICT_ALL_TABLES 则对所有表生效（包括 MyISAM）。但注意：**无论哪个开启，ALTER 操作本身都走严格校验逻辑，不受此区分影响**——因为 DDL 不在事务上下文中执行。
- 查当前模式：
SELECT @@sql_mode;
看输出里有没有STRICT_TRANS_TABLES或STRICT_ALL_TABLES - 线上库通常两者都开，别指望靠关掉其中一个绕过截断检查
- 真正影响 ALTER 行为的是 MySQL 版本：8.0.19+ 对部分隐式转换更敏感，5.7 相对宽松些（但依然报错）
安全缩容字段的三步操作法
想把一个字段变短又不想丢数据？不能跳步。核心是把“隐式转换”变成“显式可控处理”。
- 加临时列存清洗后数据：
ALTER TABLE t ADD COLUMN col_new VARCHAR(50);
- 用 SUBSTRING 或 LEFT 显式截断并写入：
UPDATE t SET col_new = LEFT(col_old, 50);
（确保没 NULL 冲突） - 删旧列、重命名新列：
ALTER TABLE t DROP COLUMN col_old, CHANGE col_new col_old VARCHAR(50);
这方法慢但安全。别图快用 MODIFY 强行压，尤其当表大、行多时，失败回滚成本远高于分步执行。
JSON 字段改类型时的特殊截断陷阱
把 TEXT 改成 JSON 类型时，MySQL 不仅检查长度，还会验证 JSON 语法。哪怕内容长度没超，只要某条记录是 "{a:1}"（key 缺引号），就会报 Data truncated——它把解析失败也归为此类错误。
- 提前验证 JSON 合法性：
SELECT id, column_name FROM t WHERE JSON_VALID(column_name) = 0;
-
JSON类型底层仍是LONGTEXT，所以缩容限制比普通字符串更严：最大长度不能低于实际最长合法 JSON 字符串 - 别用
CAST(... AS JSON)在 ALTER 中兜底：DDL 不支持表达式转换，会语法报错
字段类型变更本质是数据契约的重签，MySQL 强制你面对真实数据分布。跳过验证步骤，后面查不出的脏数据比报错更难缠。
