在客户发布版本中加入运行时DDL以兼容数据库是否合规？

问题1：在面向客户的已发布版本中添加DDL操作是否合理？ #

这得看具体场景，但不是绝对不合理——如果是为了适配新版本功能、修复数据结构缺陷，或者保证新旧版本兼容，这种操作是有必要的，但一定要把风险控制到位：

• 首先要确保DDL是兼容旧版本的，比如你例子里加的是可选字段hsssoid，不会影响旧版本代码的正常运行；
• 执行DDL时要警惕数据库锁的问题，尤其是对大表操作，可能会阻塞其他业务请求，最好选在业务低峰期执行，或者用支持在线DDL的工具（比如MySQL的pt-online-schema-change）减少影响；
• 必须提前做好备份和回滚方案，万一执行出问题能快速恢复数据；
• 别忘了和客户提前沟通，告知操作时间、可能的短暂影响，避免突然操作引发客户恐慌。

问题2：运行时每次计算薪资执行指定DDL是否可行？ #

你提到的这段运行时执行的DDL：

IF NOT EXISTS (SELECT * FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = 'person_data' AND COLUMN_NAME = 'hsssoid') 
BEGIN 
    ALTER TABLE person_data ADD hsssoid varchar(20) 
END

从功能上看，它确实能保证目标字段存在，但这种实现方式非常不推荐，主要有这些隐患：

• 高频冗余开销：每次计算薪资都要查询系统表INFORMATION_SCHEMA.COLUMNS，哪怕字段已经存在，这会额外消耗数据库资源，要是薪资计算是批量高频操作，累积的开销会很明显；
• 并发冲突风险：如果多个薪资计算请求同时触发这段DDL，可能会出现并发执行ALTER TABLE的冲突，轻则报错中断业务，重则导致数据库锁死；
• 权限安全隐患：应用程序账号需要拥有ALTER TABLE的权限，这会扩大权限范围，一旦应用被攻击，数据库面临的风险会更高。

更优的替代方案 #

• 部署时一次性执行：用数据库迁移工具（比如Flyway、Liquibase），在部署新版本时由专门的迁移账号执行一次DDL，工具会自动标记执行状态，后续不会重复触发；
• 应用启动时执行：在应用初始化阶段（比如Spring Boot的ApplicationRunner）执行一次这段DDL，确保应用启动后数据库结构符合要求，避免运行时反复执行；
• 提前预执行：如果客户环境允许，在部署新版本前，先由客户的DBA完成DDL操作，应用启动后直接使用即可。

内容的提问来源于stack exchange，提问作者pnbps