必须用虚拟列+索引才能高效查询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 虽然支持函数索引，但只对「确定性函数 + 确定性参数」生效，而 ->> 是确定的，可直接用于索引定义

必须用虚拟列暴露关键字段

把常用查询路径“具象化”成真实列，再加索引——这是唯一靠谱的高性能方案。

• 建表时定义虚拟列：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 的区别必须分清

更新配置时选错函数会导致意外丢数据。

jm-jsjkxyjs02-zlm-405

使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。

下载

• 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'，索引照样失效——函数索引不支持运行时包装。