配置项变更必须带版本号和生效时间
直接在配置表里 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。
