数据库变更看起来只是一条 SQL，但它通常连接着接口、页面、任务、报表和历史数据。一条字段变更如果没有检查影响范围，轻则联调失败，重则锁表、主从延迟、线上功能异常。
发布前确认影响范围
先确认变更对象：库名、表名、字段名、索引名、数据量、业务入口和读写频率。新增字段要写清默认值、是否允许为空、单位和时区语义；新增索引要说明服务哪个查询条件，避免“看起来有用”的冗余索引。
如果是修改字段类型、删除字段、调整唯一约束这类高风险动作，要先检查代码引用、历史数据分布和回滚路径。个人开发库可以直接收敛模型，但真实生产库不能把“开发期方便”当作发布理由。
DDL 执行要看锁和耗时
MySQL 的在线 DDL 能减少阻塞，但不是所有操作都无锁。执行前最好确认数据库版本、表引擎、变更算法和是否会重建表。大表变更要考虑低峰期、分批迁移或使用专门工具。
发布时不要只看 SQL 执行成功，还要观察连接数、慢查询、主从延迟和应用错误日志。索引创建成功并不代表业务已经安全，新的执行计划可能让另一个查询变慢。
回滚不是一句“删掉字段”
数据库回滚要分情况。新增字段通常可以先保留，不一定立即删除；新增索引可以评估后删除；数据回填和字段语义修改则要提前准备反向脚本或补偿方案。
最稳的发布方式是让代码兼容一个短窗口：先加字段和索引，再发布写入逻辑，再切换读取逻辑，最后清理旧结构。未上线项目可以更快收敛，但每一步仍要能验证。
发布后必须复查
变更完成后，至少跑一组核心查询、接口调用和页面验证。对于主从架构，还要确认从库延迟恢复正常，报表和异步任务没有因为字段变化失败。
数据库发布清单的价值不在于形式，而在于把“这条 SQL 会影响谁、失败后怎么办、上线后看什么”提前说清楚。这样 DDL 才不会变成上线窗口里的盲盒。
正文完
