JSONB和JSON在PostgreSQL中本质不同：JSON存储原始文本、每次查询需重新解析，JSONB则以二进制格式存储、支持索引且查询更快；二者在键序、空格处理及性能上存在根本差异。
JOIN里直接用jsonb_array_elements()或JSON_TABLE()会触发全行解析
PostgreSQL 的 jsonb_array_elements() 和 MySQL 的 JSON_TABLE() 都不是“零开销函数”——它们对每一行原始记录，都要完整加载、解析整个 JSON 数组二进制内容，再逐个拆成新行。这不是索引扫描，是纯 CPU 解析。当 JOIN 前已有 10 万行主表数据，展开后变成 50 万行，就意味着至少 10 万次 JSON 解析 + 50 万次内存分配和结构化构造。
常见错误是把展开逻辑塞进 JOIN 条件里，比如：
SELECT * FROM orders o JOIN LATERAL jsonb_array_elements(o.items) AS elem ON true JOIN products p ON (elem->>'id')::int = p.id;
这会让 PostgreSQL 对每条 o.items 先解析数组，再为每个元素做一次 p 表查找 —— 解析动作无法复用，也不能下推到索引层。
被驱动表关联字段是 JSON 提取值，导致索引失效
即使你在 products.id 上有主键，只要 JOIN 条件右侧是动态提取的 JSON 值（如 (elem->>'id')::int），MySQL/PG 就无法利用该索引做快速定位。本质是：优化器看到的是一个运行时计算表达式，不是稳定列值。
必须提前物化这个值，并确保它能走索引：
- PostgreSQL：在
(payload->>'user_id')::bigint上建函数索引：CREATE INDEX idx_orders_user_id ON orders ((payload->>'user_id')::bigint) - MySQL：用虚拟列 + 普通索引：
ALTER TABLE orders ADD COLUMN item_id BIGINT AS (CAST(items->>'$.id' AS UNSIGNED)) STORED，再建索引 - 千万别依赖
ON elem->>'id' = p.id这种写法——类型隐式转换会让索引彻底失效，且 NULL 传播导致匹配静默丢失
展开后中间结果集暴涨，JOIN 算法被迫退化为 Block Nested-Loop
JSON 数组平均长度 5，10 万订单就生成 50 万中间行；若再 JOIN 一张 100 万行的产品表，嵌套循环次数可能突破亿级。MySQL 在内存不足时自动启用 Block Nested-Loop（BNL），把驱动表分块缓存，但每块仍要反复扫描被驱动表 —— 这会引发大量 CPU 密集型内存拷贝和哈希计算，SHOW PROCESSLIST 里常看到状态为 Creating sort index 或 Copying to tmp table。
更隐蔽的问题是：展开后的临时结果没有统计信息，优化器误判行数，选错驱动表顺序。实测中，把原本应作为驱动表的小表（如 products）错当成被驱动表，CPU 使用率直接从 40% 拉满到 100%。
触发器或审计逻辑在展开路径上二次介入
如果目标表上有 INSERT/UPDATE 触发器，而触发器里又调用了 JSON_CONTAINS、JSON_OBJECT 或日志写入，问题会指数级放大。例如一个订单插入触发器里执行：
INSERT INTO audit_log(event, payload) VALUES ('order_items_expanded', JSON_OBJECT('items_count', JSON_LENGTH(NEW.items)));这会导致每条原始订单都额外触发一次 JSON 解析 + 构造 + 序列化。而展开 JOIN 本身已让单条语句处理行数 ×5，触发器开销也跟着 ×5 —— CPU 不是被查询拖垮的，是被自己加的“审计装饰”压垮的。
真正难调试的点在于：这种 CPU 满载不会报慢查询日志，EXPLAIN 看不出异常，perf top 却显示 json_parse_value 或 json_dom::parse 占比极高。别只盯着 JOIN 写法，先关掉触发器，确认是否回归正常。
