业务需求多变，如何动态增加数据库表字段才更优雅？

直接执行DDL语句（最常见的方式）

这是最直接、最传统的方法，通过执行数据定义语言（DDL）命令来修改表结构，几乎所有的关系型数据库都支持ALTER TABLE语句来添加新字段。

基本语法示例：

MySQL:

ALTER TABLE `users` ADD COLUMN `nickname` VARCHAR(50) NULL COMMENT '用户昵称';

PostgreSQL:

ALTER TABLE users ADD COLUMN nickname VARCHAR(50) NULL;

SQL Server:

ALTER TABLE users ADD nickname VARCHAR(50) NULL;

优点：

缺点与风险：

锁表风险：在多数数据库中，执行ALTER TABLE会锁定整个表，直到操作完成，对于大型表（千万级数据量以上），这个过程可能持续数秒甚至数分钟，期间所有对该表的读写请求都会被阻塞，导致应用服务不可用，尽管现代数据库（如MySQL 8.0、PostgreSQL）推出了“在线DDL”功能，可以在大部分DDL操作期间不阻塞DML,但在某些极端情况下仍可能存在锁表或性能抖动。
部署复杂性：数据库结构的变更需要与应用程序的更新进行协同，必须先修改数据库，再部署能够识别新字段的程序代码,否则新程序无法启动或旧程序会出错。

当业务场景需要极度灵活，字段增减极为频繁，且无法承受频繁DDL操作带来的风险时，可以考虑不修改表结构,而是通过设计模式来间接实现。

EAV（Entity-Attribute-Value）模式

EAV模式将数据的存储方式从“行-列”模型转变为“实体-属性-值”三元组模型,通常需要三张表：

当需要增加“字段”时，只需在“属性表”中增加一条记录即可,无需触动任何表结构。

优点：

缺点：

JSON/JSONB 字段

现代数据库（如PostgreSQL, MySQL 5.7+）提供了对JSON数据类型的原生支持，可以在表中预留一个JSON或JSONB类型的字段（如attributes）,用于存储所有动态的键值对。

示例：

-- PostgreSQL 示例
UPDATE products SET attributes = '{"color": "red", "size": "L"}' WHERE id = 1;

优点：

缺点：

为了更清晰地选择,我们可以通过一个表格来对比这几种方案。

方案	灵活性	查询性能	数据完整性	开发复杂度	适用场景
直接DDL	低	高	强	低	绝大多数标准业务场景
EAV模式	极高	极低	弱	高	需要存储高度自定义元数据的场景，如电商产品属性
JSON字段	高	中等	中等	中等	需要半结构化数据，且对性能有一定要求的场景

最佳实践建议：

对于绝大多数业务系统，首选并推荐采用“直接执行DDL”的方式,但必须辅以规范的流程来规避风险：

数据库版本控制：使用Flyway、Liquibase等工具，将DDL脚本像代码一样进行版本管理，确保所有环境的数据库结构变更可追溯、可回滚。
灰度发布策略：遵循“先加字段，后改代码”的原则。
- 第一步：在业务低峰期，执行ALTER TABLE命令，新增一个允许为NULL的字段。
- 第二步：部署新版本的应用程序，该程序能同时处理新旧字段（写入时同时写入两个字段，读取时优先读取新字段）。
- 第三步：运行一个后台脚本，将旧数据（如果需要）填充到新字段中。
- 第四步：确认所有数据迁移完毕后，再部署最终版本的应用程序，该版本完全使用新字段,并可以移除对旧字段的兼容逻辑。
充分测试：在生产环境执行前，必须在与生产环境数据量相当的预发环境中进行充分测试,评估DDL操作的耗时和影响。