MySQL 5.7及以下版本不支持DROP COLUMN语法，执行会报ERROR 1064；仅8.0+原生支持，且多字段删除须写为DROP COLUMN f1, DROP COLUMN f2，不可简写为DROP COLUMN f1, f2。
直接执行 DROP COLUMN 会报错？先确认 MySQL 版本
MySQL 5.7 及以下版本不支持 DROP COLUMN 语法，强行执行会报错 ERROR 1064 (42000)。只有 MySQL 8.0+ 才原生支持该操作。如果你用的是 MariaDB，需确认版本 ≥ 10.3.2（对应 MySQL 8.0 兼容性），否则也得绕路。
快速验证方式：
SELECT VERSION();
- 结果以
8.0.开头 → 可直接用ALTER TABLE ... DROP COLUMN - 结果是
5.7.或更低 → 必须用“重建表”方式（见下一条） - 不确定生产环境版本？先在测试库跑
ALTER TABLE t1 DROP COLUMN c1;验证，别直接上线
MySQL 5.7 怎么安全删字段：用 CREATE TABLE ... SELECT 替代
不能删列，就换一张“干净”的表。核心思路是：导出保留字段 + 重命名替换。注意这不是简单复制，而是带结构、索引、约束的重建。
假设要从表 orders 中删除无用字段 old_comment，保留其他所有字段：
CREATE TABLE orders_new AS SELECT id, user_id, amount, created_at FROM orders; ALTER TABLE orders_new ADD PRIMARY KEY (id); -- 手动补回原表的索引、外键、注释（<code>SHOW CREATE TABLE orders</code> 查） RENAME TABLE orders TO orders_bak, orders_new TO orders;
- 必须显式列出所有**需要保留**的字段，不能写
SELECT *，否则旧字段还在 -
CREATE TABLE ... AS SELECT不继承原表的索引、AUTO_INCREMENT、DEFAULT、COMMENT，这些全得手动补 - 大表慎用：过程中会锁表（
RENAME是原子操作，但前面建表和加索引阶段可能阻塞写入）
删字段前务必检查三类依赖，否则服务直接报错
字段不是孤立存在的。删之前不扫一遍，应用层可能突然抛 Unknown column 'xxx' in 'field list' 或更隐蔽的逻辑错误。
- SQL 查询：grep 项目代码里所有
SELECT *、INSERT INTO table（没列名）、UPDATE table SET语句，确认是否引用了该字段 - 视图与存储过程：
SHOW CREATE VIEW view_name;、SHOW CREATE PROCEDURE proc_name;，检查定义中是否包含该字段 - ORM 映射：比如 Django 的
models.py、MyBatis 的resultMap，字段名若硬编码在映射里，删库字段后 Java/Python 层会反序列化失败
为什么不能用 ALTER TABLE ... DROP COLUMN 同时删多个字段？
MySQL 8.0+ 支持一次删多个字段，但语法不是逗号分隔，而是重复写 DROP COLUMN。写成 DROP COLUMN a, b 会语法错误。
正确写法：
ALTER TABLE orders DROP COLUMN old_comment, DROP COLUMN temp_flag;
- 每个
DROP COLUMN独立解析，中间用逗号分隔，但关键字不能省略 - 如果字段有默认值、约束或被生成列引用，MySQL 会拒绝删除，报错如
ERROR 3794 (HY000)—— 此时得先ALTER TABLE ... DROP DEFAULT或改写生成列表达式 - 线上操作建议单字段分批执行，便于出问题时快速回滚（备份原表比恢复多字段删错容易得多）
实际删字段最耗时间的环节往往不是 SQL 执行，而是确认依赖和协调上下游——字段看着“无用”，可能正被某个凌晨跑的报表脚本悄悄读着。
