MySQL配置表需支持热读取、避免锁表、兼容多环境且不拖慢主业务；必须含env字段和联合唯一索引，按类型分列存储并加CHECK约束，读取须走带主动失效通知的本地缓存，updated_at应使用ON UPDATE CURRENT_TIMESTAMP确保时间统一。
MySQL 配置表不是“建个表随便插几条就行”，核心在于：它得支持运行时热读取、避免频繁锁表、兼容多环境（dev/test/prod）、且不拖慢主业务查询。直接用 key/value 两个字段硬扛，后期必踩坑。
配置表必须带 env 字段和唯一约束
同一套代码跑在开发、测试、生产环境，配置值往往不同。如果只靠应用层切换数据库或靠注释区分，极易误操作。正确做法是把环境维度下沉到表结构里：
CREATE TABLE `config` (
`id` BIGINT PRIMARY KEY AUTO_INCREMENT,
`key` VARCHAR(128) NOT NULL,
`value` TEXT,
`env` ENUM('dev', 'test', 'prod') NOT NULL DEFAULT 'dev',
`updated_at` DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
UNIQUE KEY `uk_key_env` (`key`, `env`)
);
这样查配置时加 WHERE `key` = 'api.timeout' AND `env` = 'prod' 就能精准命中，不会因环境错配导致故障。漏掉 env 或没建联合唯一索引，会导致重复插入、覆盖混乱、上线后值不对却查不出原因。
别用 TEXT 存所有值，按类型分列 + type 字段更可控
全用 TEXT 看似灵活，实际带来三个问题：无法加校验（比如 timeout 应该是正整数）、没法走索引范围查询（如查所有大于 3000 的超时配置）、JSON 解析全靠应用层——出错难定位。
- 把常用类型拆成显式字段：
value_int、value_str、value_bool、value_json - 加
type字段限定当前行有效字段，例如type = 'int'表示只读value_int - 写入时由应用层校验并填充对应字段，数据库层用
CHECK约束兜底（MySQL 8.0.16+ 支持）
这样既保留扩展性，又让数据可验证、可审计、可被 DBA 理解。
读配置必须走缓存，且缓存失效要主动通知
每次 HTTP 请求都查一次 config 表，哪怕加了索引，QPS 上千就容易成瓶颈。但缓存不能简单设个 5 分钟过期——配置改了，业务要等 5 分钟才生效，等于失去配置表意义。
- 应用启动时全量加载进本地内存（如 Go 的
sync.Map、Java 的ConcurrentHashMap） - 搭配一个轻量监听机制：比如用 MySQL 的
SELECT ... FOR UPDATE加个哨兵行，或监听 binlog 中config表变更（推荐canal或maxwell） - 收到变更后，精确刷新对应
key的缓存项，而不是清空全部
跳过这步，所谓“动态配置”只是假象——你改了数据库，服务根本不知道。
updated_at 要用 ON UPDATE CURRENT_TIMESTAMP，别靠应用写
很多团队让应用自己拼 now() 写入时间，结果各服务时区不一致、NTP 同步延迟、甚至写错字段，导致无法判断哪次更新才是最新。MySQL 原生的 ON UPDATE CURRENT_TIMESTAMP 是唯一可信来源。
注意两点：
- 字段类型必须是
DATETIME或TIMESTAMP，TIMESTAMP会自动转时区，DATETIME更稳妥 - 不要用
DEFAULT CURRENT_TIMESTAMP和ON UPDATE CURRENT_TIMESTAMP同时作用于两个字段——MySQL 5.6 有 bug，可能导致插入失败
配置表的可靠性，藏在这些细节里：少一个约束、漏一个环境、缓存不同步、时间不统一，都会让“改个开关就生效”变成“重启服务才管用”。
