ThinkPHP 6.0 不干预 MySQL 索引机制，JSON 字段查询优化依赖 MySQL ≥5.7.8 的虚拟/存储生成列+索引策略，TP6 仅生成标准 SQL；需将 JSON 内部键提取为普通字段（如 v_action）并建索引，禁止在 where 中直接使用 ->> 语法，否则退化为全表扫描。
ThinkPHP 6.0 本身不直接干预 MySQL 的索引机制，JSON 字段的索引创建与查询优化完全依赖底层 MySQL 版本能力（需 ≥5.7.8，推荐 ≥8.0.13）。TP6 只负责生成符合规范的 SQL，真正起效的是你为 JSON 内部字段设计的索引策略。
明确 JSON 字段无法直接建索引
MySQL 不支持对整个 JSON 列建立 B+Tree 索引。像 CREATE INDEX idx_json ON table(json_col) 这类写法看似合法，但实际无法加速 WHERE json_col->>'$.key' = 'val' 这类查询——执行计划仍显示全表扫描。
必须把目标键值“提取出来”，变成普通列，再对其建索引。主流方案有两种：
- 虚拟生成列（MySQL 5.7.8+）：不占磁盘空间，查询时实时计算，适合读多写少、计算轻量的字段
- 存储生成列（MySQL 5.7.8+）：数据写入时即计算并落盘，查询更快，但增加存储和写入开销
用虚拟列 + 索引实现高效查询
以 TP6 常见的日志表为例，假设表 user_logs 含 JSON 字段 extra，结构如 {"action":"login","ip":"192.168.1.100","device":"mobile"}，你想按 action 快速筛选：
先在 MySQL 中执行：
ALTER TABLE user_logs ADD COLUMN v_action VARCHAR(32) GENERATED ALWAYS AS (JSON_UNQUOTE(JSON_EXTRACT(extra, '$.action'))) VIRTUAL; <p>CREATE INDEX idx_v_action ON user_logs(v_action);
之后在 TP6 中正常查询即可命中索引：
// TP6 查询写法（等价于 SELECT * FROM user_logs WHERE v_action = 'login'）
Db::name('user_logs')->where('v_action', 'login')->select();注意：v_action 是新增的普通字段名，不是 JSON 路径；TP6 不识别 ->> 语法，所以不能写 where('extra->>\'$.action\'', 'login')——那会退化为全表扫描。
MySQL 8.0.17+ 支持多值索引（数组场景）
若 JSON 字段存的是数组，例如 "tags": ["php", "mysql", "tp6"]，且需查“含某个 tag”的记录，传统方式难索引。MySQL 8.0.17 起支持多值索引：
ALTER TABLE posts ADD COLUMN v_tags VARCHAR(255) GENERATED ALWAYS AS (JSON_EXTRACT(tags, '$[*]')) STORED; <p>CREATE INDEX idx_tags ON posts(v_tags) USING BTREE;
或更简洁地使用函数索引（8.0.13+）：
CREATE INDEX idx_tag_search ON posts((CAST(JSON_EXTRACT(tags, '$[*]') AS CHAR(255))));
查询时用 JSON_CONTAINS(tags, '"mysql"')，配合该索引可走 range 扫描，性能显著优于无索引时的全表遍历。
TP6 开发中要避开的坑
- 别在
where()中直接用->>表达式：TP6 会原样拼进 SQL，MySQL 无法利用索引 - 避免高频更新大 JSON 文档：每次更新都触发生成列重算，尤其存储列会加重 I/O
- 数组元素查询慎用
JSON_CONTAINS：它内部是字符串匹配，大数据量下仍可能慢；优先考虑拆成关联表或用多值索引 - 字段长度预估要留余量：
VARCHAR(32)若实际值超长会被截断，导致索引失效或查不到数据
本质上，TP6 是个透明通道。JSON 查询快不快，取决于你是否在 MySQL 层把路径值“具象化”为可索引的列，并配好对应索引。不复杂但容易忽略。
