MySQL 5.7 中 JSON 字段查询无法走索引下推（ICP），根本原因是 JSON 路径表达式（如 ->> 或 JSON_EXTRACT）属于运行时函数调用，发生在 server 层且依赖 JSON 解析器，InnoDB 引擎层无法识别和下推；只有通过 STORED 生成列物化为真实标量列并建索引后，才能满足 ICP 前提——即 WHERE 条件必须直接引用该生成列名，且字符集/排序规则严格一致。
MySQL 5.7 的 JSON 字段查询无法走索引下推（ICP），根本原因不是“没实现”，而是**JSON 路径表达式本身不满足 ICP 的前提条件**：它不是可下推的“索引列谓词”。
为什么 JSON_EXTRACT() 或 ->> 不算索引列谓词
索引下推（Index Condition Pushdown）要求 WHERE 条件中涉及的列必须是索引的一部分，且该列的值在存储引擎层可直接计算、比较。而 JSON_EXTRACT(data, '$.status') 或 data->>'$.status' 是一个运行时函数调用，其输入是整行的 data 字段（BLOB 类型），输出依赖于 JSON 解析器逐字节解析——这个过程发生在 server 层，无法下沉到 InnoDB 引擎层执行。
换句话说：InnoDB 看不到 “status 值是多少”，它只看到一串二进制 JSON 数据；没有对应物理列，就没有下推对象。
- 即使你建了
INDEX(data(10))，MySQL 也会报错或静默忽略——JSON类型不支持前缀索引 -
VIRTUAL列虽能定义路径表达式，但 5.7 不允许对其建索引，自然也无 ICP 可言 - 只有
STORED生成列才是真实落盘的标量值，才能成为索引键，进而支持 ICP
为什么 STORED 生成列 + 索引才能启用 ICP
当你执行：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
ALTER TABLE t ADD COLUMN status VARCHAR(20) AS (JSON_UNQUOTE(JSON_EXTRACT(data, '$.status'))) STORED;<br>CREATE INDEX idx_status ON t(status);
这时 status 是一个真实存在的、类型确定的字符串列，值在 INSERT/UPDATE 时已物化并存入 B+ 树索引页。InnoDB 在读取索引项时，就能直接用 status = 'active' 过滤，无需回表再计算——这就是 ICP 发挥作用的完整链路。
- ICP 生效前提是：WHERE 中的条件字段名必须和生成列名完全一致，不能写成
JSON_EXTRACT(data, '$.status') - 如果生成列定义里漏了
JSON_UNQUOTE()，值会带双引号（如"active"），导致等值匹配失败 -
STORED关键字不可省略；5.7 中VIRTUAL列无法建索引，更谈不上 ICP
常见误判：EXPLAIN 显示 "Using index condition" 却没提速
这种现象通常是因为字符集隐式转换破坏了 ICP。例如：
- 生成列定义未显式指定
COLLATE，而源 JSON 字段是utf8mb4_bin - 导致生成列实际用了
utf8mb4_0900_as_cs，与查询字面量'active'的 collation 不一致 - MySQL 自动触发隐式转换，强制将索引值转为另一 collation 比较，ICP 失效，退化为全索引扫描
- 验证方法：
SHOW FULL COLUMNS FROM t LIKE 'status'查看Collation是否与业务预期一致
真正容易被忽略的，不是“要不要加索引”，而是生成列的 COLLATE 是否与查询字面量对齐——差一个排序规则，ICP 就彻底失效。
