配置表设计核心是动态可管、可查、可审计，需围绕“谁改的、为什么改、改成什么样、何时生效”建模，含基础字段（param_key、param_value 等）和增强字段（comment、apply_scope 等），并配套同步机制、差异比对和操作日志。
配置表设计的核心是把 MySQL 系统参数从硬 编码 或配置文件 中抽离出来，实现动态可管、可查、可审计。关键不是堆字段，而是围绕“谁改的、为什么 改、改成什么样、何时生效”来建模。
基础字段：必须覆盖生命周期
一张最小可用的配置表至少包含以下字段：
- param_key：参数名（如 innodb_buffer_pool_size），主键或唯一索引，避免重复；
- param_value：当前生效值（字符串存储，兼容数字 / 布尔 / 内存单位等格式）；
- default_value：MySQL 默认值（便于对比和回滚）；
- is_dynamic：布尔值，标识是否支持 SET GLOBAL 动态修改；
- last_modified：时间戳，记录最近一次人工修改时间；
- modified_by：操作人（账号或工号），用于责任追溯；
- status：状态字段（如 active / pending_restart / disabled），区分是否需重启才生效。
增强字段：支撑变更与审计
生产环境建议增加这些字段提升可观测性：
- comment：修改原因（例：“为应对 Q4 订单峰值，buffer pool 由 2G 调至 6G”）；
- apply_scope：作用范围（global / session / both）；
- value_type：值类型（int / string / bool / size），辅助 前端 校验和展示；
- min_value、max_value：数值型参数的合法边界（如 max_connections 不能设为 -1）；
- version_tag：关联 MySQL 版本（5.7 / 8.0.33），因为同一参数在不同版本行为可能不同。
配套机制：光有表不够
配置表只是载体，真正落地需要三类支撑：
- 同步机制：定时任务或触发器将表中 active 参数写入 MySQL（用 SET PERSIST 或更新 mysqld-auto.cnf），并校验执行结果；
- 差异比对：启动时或定期扫描 SHOW VARIABLES，把实际运行值与表中 param_value 对比，发现不一致自动告警；
- 操作日志表 ：单独一张 config_change_log，记录每次修改前值、后值、SQL 语句、IP、客户端 工具 等，满足等保审计要求。
避坑提醒：常见设计失误
实际项目里容易踩的坑：
- 把所有参数塞进一张表，却没区分“系统级”（影响全局）和“租户级”（按 DB 或用户隔离）——后者应拆成关联表；
- 用 TEXT 存 param_value，导致无法建索引、难排序、JSON 解析失败；
- 忽略只读参数（如 version、uptime），表里误填造成误导；
- 没做权限控制，开发能直接 UPDATE 配置表，绕过审批流程。
