XML/JSON字段无法直接使用B+树索引，查询时需逐行解析，嵌套查询会反复解析、放大开销，执行计划不显示解析耗时；有效优化是提前物化关键字段并建索引。
XML/JSON字段无法直接走B+树索引
SQL Server 和 MySQL 等数据库的原生索引（如 B+树索引）只作用于普通列，对 XML 或 JSON 类型字段本身不生效。当你写 WHERE order_data.exist('/root/item[@status="shipped"]') = 1 或 WHERE JSON_EXTRACT(payload, '$.user.id') = '123'，数据库必须逐行解析整个 XML/JSON 字符串才能比对——这本质是全表扫描 + CPU 解析开销。
嵌套查询会放大解析次数
如果把 XML/JSON 查询嵌在子查询里，比如：
SELECT * FROM orders
WHERE customer_id IN (
SELECT customer_id FROM customers
WHERE profile.exist('/contact/country[text()="CN"]') = 1
)那外层每匹配一个 customer_id，内层都可能重新解析一遍 profile 字段。嵌套越深、驱动表结果越多，解析总次数就呈倍数增长。这不是“一次解析复用”，而是“反复解析”。
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- XML 的
.exist()、.value()每次调用都触发完整 DOM 构建和 XPath 求值 - JSON 的
JSON_VALUE()或->>操作符在无索引支撑时，每次执行都要字符串切分 + JSON 解析 - SQL Server 中未绑定
XML Schema Collection的 XML 列，连基础类型推断都靠猜，进一步拖慢解析
执行计划里看不到真实代价
数据库的 EXPLAIN 或 SET STATISTICS XML ON 能显示是否用了索引、扫描多少行，但不会告诉你“这一行 XML 解析花了 8ms”。你看到 rows=1000，实际可能是 1000×（平均解析耗时），而这个耗时被摊在 CPU 时间里，容易误判为“IO 问题”或“锁等待”。尤其在并发高时，CPU 被 JSON/XML 解析吃满，sys.dm_exec_requests 里只显示 status = running，没有明显阻塞信号。
替代方案不是“改写语法”，而是“提前物化”
真正有效的优化不是把 IN (SELECT ...) 改成 JOIN，而是让 XML/JSON 里的关键字段“脱离嵌套结构”：
- SQL Server：用
ALTER TABLE ... ADD status AS payload.value('(/order/@status)[1]', 'varchar(20)') PERSISTED创建持久化计算列，再在该列建索引 - MySQL：用
GENERATED COLUMN提取JSON_EXTRACT(data, '$.user.email')并加索引 - PostgreSQL：直接在表达式上建函数索引
CREATE INDEX ON logs ((data->>'level'))
这些操作把运行时解析变成写入时计算，查询时就退化为普通等值查找——这才是绕过嵌套低效本质的关键。否则，再怎么重写 SQL 结构，只要还在查原始 XML/JSON 字段，就逃不开逐行解析这个硬伤。
