ALTER TABLE MODIFY COLUMN 会丢失数据吗
直接用
MODIFY COLUMN修改字段类型时，是否丢数据取决于新旧类型的兼容性。比如把
VARCHAR(50)改成
VARCHAR(20)，超出长度的值会被截断——MySQL 默认不报错，只发 warning；而把
INT改成
TINYINT，原本大于 127 的值会变成 127 或溢出后的模值。 执行前务必先查
SELECT MAX(LENGTH(column_name)), COUNT(*) FROM table_name确认当前数据长度/范围 开启严格模式（
STRICT_TRANS_TABLES）能让截断触发错误而非静默处理 时间类型转换最危险：从
DATETIME改为
DATE会直接丢掉时分秒，且不可逆
CHANGE COLUMN 和 MODIFY COLUMN 有什么区别
CHANGE COLUMN必须写两次字段名（原名 + 新名），能同时改名和类型；
MODIFY COLUMN只改类型或属性，不能改字段名。实际修改字段类型时，若不需要重命名，优先用
MODIFY——语义更清晰，也少写一遍字段名，降低拼错风险。 想改名又改类型：用
CHANGE COLUMN old_name new_name VARCHAR(100) NOT NULL只改类型或
NOT NULL属性：用
MODIFY COLUMN col_name TEXT两者都支持加/删默认值、注释，但
CHANGE在语法上更“重”，部分 ORM 或迁移工具对它解析更严格
TEXT/BLOB 字段能直接加索引吗
不能直接在完整
TEXT或
BLOB字段上建普通索引，MySQL 会报错
ERROR 1170 (42000): BLOB/TEXT column 'xxx' used in key specification without a key length。必须指定前缀长度，比如
INDEX idx_content (content(255))。 前缀长度不能超过 3072 字节（InnoDB，默认页大小下），utf8mb4 编码下最多约 768 个字符 如果字段常用于
WHERE content = ?等精确匹配，建议改用
VARCHAR并设足够长度，比前缀索引更可靠 全文索引（
FULLTEXT）是例外，它专为
TEXT设计，但仅支持 MyISAM 和 InnoDB（5.6+），且查询语法不同
修改大表字段类型为什么特别慢
MySQL 5.6 之前，
ALTER TABLE修改字段类型本质是“重建表”：拷贝全量数据到临时表，改完再 rename。一张千万行的表可能卡住数小时，期间写操作被阻塞。 5.6+ 的 InnoDB 支持部分
INPLACE算法，比如加
NOT NULL、扩大
VARCHAR长度（不缩小）、改
ENUM值列表等，速度较快 但改类型（如
INT→
BIGINT）、缩小长度、改字符集，仍需拷贝数据 生产环境务必在低峰期操作，并提前用
pt-online-schema-change或
gh-ost做在线变更——它们通过影子表+触发器实现无锁
真正麻烦的不是语法怎么写，而是改之前没看存量数据分布、没评估锁影响、也没准备回滚方案。线上改字段，宁可多花半小时验证，别信“就改一个字段很快”。
