配置项变更必须通过插入而非更新实现，使用version和effective_at双字段控制生命周期，确保可追溯、可回滚、可灰度；version建议用自增BIGINT或语义化字符串，effective_at表示生效时间且需唯一索引约束。
配置项变更必须带版本号和生效时间
直接在配置表里 UPDATE 会导致历史不可追溯、回滚困难、灰度验证缺失。所有写入必须走插入，用 version + effective_at（datetime）双字段控制生命周期。
-
version建议用BIGINT AUTO_INCREMENT或语义化字符串（如'v1.2.0'），避免用时间戳——并发插入可能乱序 -
effective_at存的是「该版本从何时开始生效」，不是「何时写入」；可设默认值CURRENT_TIMESTAMP，但必须允许手动覆盖 - 加唯一索引：
UNIQUE KEY uk_config_key_version (config_key, version)，防重复发布
查询最新生效配置要绕开 MAX(version) 子查询
用 SELECT ... WHERE effective_at 是常见错误——它依赖「最后发布的一定是最新的」，但实际可能有延迟发布（比如预设下周一生效的版本）。
- 正确做法是：先查出所有
effective_at 的记录，再取 <code>version最大的那条，即：SELECT * FROM config_versions WHERE config_key = 'app.timeout' AND effective_at <= NOW() ORDER BY version DESC LIMIT 1;
- 务必给
(config_key, effective_at)加联合索引，否则大表会全扫 - 如果业务要求「严格按发布时间生效」，
version字段建议改用BIGINT自增，避免语义版本排序错乱（v10.0v2.0）
上线前必须校验配置版本冲突与空窗期
运维脚本或发布平台在插入新版本前，应主动检查两件事：是否存在未生效的旧版本重叠、是否存在生效时间断层。
- 查重叠：
SELECT 1 FROM config_versions WHERE config_key = 'db.pool.size' AND effective_at < '2025-04-10 14:00:00' AND (effective_at + INTERVAL 1 DAY) > '2025-04-10 14:00:00';
（假设新版本生效时间是'2025-04-10 14:00:00'，且预期生效期为 1 天） - 查空窗：
SELECT MAX(effective_at) FROM config_versions WHERE config_key = 'cache.ttl' AND effective_at < '2025-04-10 14:00:00';
结果为空或远早于新版本时间，说明中间有断层 - 这类校验不能只靠人眼，要集成进 CI/CD 流程，失败则阻断发布
历史配置归档别用 DELETE，用分区或状态字段隔离
线上表长期堆积数万条配置版本，会影响查询性能和备份体积。但直接 DELETE FROM config_versions WHERE effective_at 风险极高——万一误删正在灰度的版本就完了。
- 推荐方案：加
status ENUM('active', 'archived') DEFAULT 'active'，归档只是UPDATE ... SET status = 'archived'，查询时显式加AND status = 'active' - 若数据量极大（千万级+），可按
YEAR(effective_at)做 RANGE 分区，但需注意 MySQL 8.0+ 才支持对 datetime 分区的高效裁剪 - 绝对不要依赖外键级联删除——配置表常被多服务读取，外键会拖慢主业务写入
真正容易被忽略的是「生效时间精度」：很多团队用 DATETIME 却没意识到它默认秒级，而服务重启、配置热加载可能发生在毫秒级窗口。如果多个版本生效时间相同，ORDER BY version DESC 就成了随机选一个。这时候要么升级到 TIMESTAMP(3)，要么强制要求发布脚本生成带毫秒的 effective_at。
