ALTER TABLE MODIFY COLUMN 可能丢失数据，取决于类型兼容性：VARCHAR 缩容会截断、INT 改 TINYINT 可能溢出、DATETIME 改 DATE 丢时分秒；严格模式可避免静默截断。
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做在线变更——它们通过影子表+触发器实现无锁
真正麻烦的不是语法怎么写，而是改之前没看存量数据分布、没评估锁影响、也没准备回滚方案。线上改字段，宁可多花半小时验证，别信“就改一个字段很快”。
