配置表设计的核心是把 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 配置表，绕过审批流程。
