删字段前须全链路验证依赖、加注释观察、按数据库特性选安全DDL方式、评估生产影响并灰度验证。冗余不等于无用，直接删除易致SQL崩、同步断流、应用静默失败。
DDL 脚本生成前必须确认字段是否真冗余
很多团队直接根据开发文档或“很久没用过”就删字段，结果上线后 select * 或 orm 映射崩了。冗余不等于无用——比如 created_at 可能没在业务逻辑里显式读取，但审计、数仓同步、下游 kafka 消费者可能依赖它。
实操建议：
- 查全链路：用
pg_depend（PostgreSQL）或INFORMATION_SCHEMA.COLUMNS+ 应用日志关键词搜索，确认该字段是否被任何 SQL、视图、存储过程、ETL 任务、BI 工具引用 - 加注释标记而非直接删：先执行
COMMENT ON COLUMN table_name.field_name IS 'DEPRECATED: no longer used after v2.3';，观察一周监控和告警 - 检查 ORM 映射：如 Django 的
models.py、MyBatis 的resultMap、TypeORM 实体类，字段名是否出现在@Column或 XML 中
生成 DROP COLUMN DDL 时注意数据库类型差异
MySQL 和 PostgreSQL 对 DROP COLUMN 的行为完全不同，盲目套用脚本会锁表或失败。
常见错误现象：ERROR: cannot drop column "xxx" because other objects depend on it（PostgreSQL），或 MySQL 执行中整个表被锁死数分钟。
实操建议：
- PostgreSQL：优先用
ALTER TABLE ... DROP COLUMN IF EXISTS xxx CASCADE;，CASCADE自动删依赖（如视图、默认表达式），但务必提前备份依赖关系 - MySQL：5.7+ 支持
DROP COLUMN，但会重建表；若表大，改用pt-online-schema-change工具生成在线 DDL，避免主从延迟和锁表 - SQL Server：需先删默认约束、索引、计算列依赖，再删字段，顺序错就报错
Cannot drop column 'xxx' because it is bound to a default
生产环境执行 DDL 前必须做变更影响评估
不是所有 DDL 都“秒级完成”。一个 DROP COLUMN 在千万级表上可能触发全表重建、复制延迟飙升、主库 CPU 爆满。
使用场景：凌晨低峰期执行 ≠ 安全。如果下游有实时同步到 ClickHouse 或 Flink 作业，字段删除会引发 schema mismatch 错误，导致数据断流。
实操建议：
- 在同规格从库上先跑一遍 DDL，用
EXPLAIN ANALYZE（PostgreSQL）或SHOW PROFILE（MySQL）看耗时与 I/O - 检查 binlog / wal 日志量：PostgreSQL 的
pg_stat_replication、MySQL 的Seconds_Behind_Master是否突增 - 确认应用连接池配置：某些 JDBC 驱动在 DDL 后会缓存元数据，不重启服务可能继续报
Unknown column 'xxx'
清理后验证不能只查表结构
\d table_name 或 DESCRIBE table_name 显示字段没了，不代表清理完成。应用层可能仍尝试写入该字段，只是被数据库静默忽略（如 MySQL 的 sql_mode 包含 STRICT_TRANS_TABLES 才报错）。
容易踩的坑：测试环境没开严格模式，生产开了，导致批量插入失败但日志里只有 “Data truncated for column 'xxx'”，极难定位。
实操建议：
- 抓包或查慢日志：在生产 DB 上开启
log_statement = 'mod'（PG）或general_log = ON（MySQL），过滤含该字段名的 INSERT/UPDATE - 检查应用层日志关键词：
Field 'xxx' doesn't have a default value、Unknown column 'xxx'、Column not found - 用影子流量验证：把生产请求复制一份打到灰度库（已执行 DDL），比对响应和错误率
最麻烦的不是删字段，是删完才发现某个定时任务的硬编码 SQL 还在拼接那个字段名——这种地方不会进版本控制，也不会被静态扫描捕获。
