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，可能导致插入失败
配置表的可靠性，藏在这些细节里：少一个约束、漏一个环境、缓存不同步、时间不统一，都会让“改个开关就生效”变成“重启服务才管用”。
