必须用虚拟列+索引才能高效查询JSON配置，因JSON_EXTRACT无法走索引；JSON_SET比JSON_REPLACE更安全；单条JSON建议≤128KB、嵌套≤5层。
直接用 JSON 类型存配置是可行的，但必须配合虚拟列 + 索引，否则查询一慢、条件一多，就会拖垮整个业务表。
为什么不能只靠 JSON_EXTRACT 做 WHERE 条件
MySQL 对 JSON 字段内部路径的过滤（比如 WHERE details->>'$.env' = 'prod'）无法走索引，每次都是全表扫描。哪怕只有几千行，加个 ORDER BY 或 LIMIT 也会明显卡顿。
- 执行计划里看到
type: ALL就说明没走索引 -
details->>'$.env'返回的是表达式结果，不是真实列，优化器没法为它建索引 - MySQL 8.0 虽然支持函数索引，但只对「确定性函数 + 确定性参数」生效，而
->>是确定的，可直接用于索引定义
必须用虚拟列暴露关键字段
把常用查询路径“具象化”成真实列，再加索引——这是唯一靠谱的高性能方案。
jm-jsjkxyjs02-zlm-405
下载
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
- 建表时定义虚拟列：
env VARCHAR(20) AS (details->>'$.env') STORED -
STORED表示物理存储，才能建索引；VIRTUAL不存磁盘，无法索引 - 给虚拟列加普通索引：
CREATE INDEX idx_config_env ON config_table(env) - 后续查询直接写
WHERE env = 'prod'，就能命中索引
JSON_SET 和 JSON_REPLACE 的区别必须分清
更新配置时选错函数会导致意外丢数据。
-
JSON_SET(json_col, '$.timeout', 3000)：键不存在就新增，存在就覆盖——安全 -
JSON_REPLACE(json_col, '$.timeout', 3000)：键不存在就静默忽略，不报错也不写入——容易埋坑 - 生产环境推荐统一用
JSON_SET，避免因字段名拼错或路径变更导致更新失效 - 如果要删字段，用
JSON_REMOVE(details, '$.deprecated_flag')，别手动拼字符串
JSON 大小和嵌套深度的实际约束
官方说最大 1GB，但真存这么大配置，等于把数据库当对象存储用了，会引发连锁问题。
- 单条 JSON 建议控制在 128KB 以内；超过 512KB 就该考虑拆分或转存文件系统
- 嵌套层级别超过 5 层（如
$.a.b.c.d.e.value），->>提取性能会明显下降，且可读性差 - MySQL 8.0 对深度嵌套的
JSON_CONTAINS有递归限制，默认最多 50 层，超了会报错ER_JSON_VALUE_TOO_BIG - 配置类数据通常只需 2–3 层（如
$.features.enabled、$.limits.max_requests），过深结构大概率是设计冗余
最常被忽略的一点：虚拟列的表达式必须和实际查询完全一致。比如你定义了 status VARCHAR(10) AS (details->>'$.status')，但查询时写了 WHERE UPPER(details->>'$.status') = 'ACTIVE'，索引照样失效——函数索引不支持运行时包装。
