一、并行查询
https://www.doubao.com/chat/collection/37124712262515970?type=Thread
1、并行查询触发时机（开发者视角，3 个条件同时满足）
纯SELECT只读查询 + 涉及千万级及以上大表 + 无高效索引的复杂查询（全表 / 范围扫描、多表关联、聚合、窗口函数等）。
（简单查询 / 小表 / 写操作 / 索引精准查询，全程单线程）
2、对开发者的核心价值
零侵入：不改 SQL / 代码，符合条件的慢查询自动提速；
省成本：兜底解决慢查询，减少 SQL 优化工作量，无需为轻量分析搭建专门数仓；
简化架构：一套 PG 库支撑 OLTP 业务 CRUD+OLAP 分析，不用拆分库、维护数据同步链路。
3、开发者仅需掌握 2 个操作
验证触发：SQL 前加EXPLAIN ANALYZE，结果有Workers Launched: N即触发；
调优并行度：SET max_parallel_workers_per_gather = N（N 为 CPU 核心数的 1/2）。
二、mysql为什么2000数据以后会变的很慢
用小区快递柜做最形象比喻，全程无专业词，一眼懂：
- B + 树 = 小区快递柜
只有最底层格子放实际快递（你的数据）；
上层所有格子，只放下层格子的编号指引（索引），不干别的。 - 快递柜有 3 个固定规矩（InnoDB 天生限制）
每层最多只有1500 个格子；
最底层每个格子，最多塞15 个快递；
格子数 / 塞件数超了，只能加一层柜子。 - 3 层快递柜最多能塞多少快递？
1 层指 1500 个 2 层格子 → 2 层共指 225 万个 3 层格子 → 3 层底层总共塞：225 万 ×15=3375 万（理论值）。
实际中格子塞不满（有空闲、有碎片），3 层最多塞2000 万个快递。 - 为啥 2000 万后变 4 层？
3 层柜子的实际容量被撑满了，放不下更多快递，只能加 1 层变成 4 层，才能继续塞数据。
最后补 1 句：为啥 4 层就慢？
取快递时，3 层只需翻 3 层柜子，4 层要多翻 1 层 → 对应数据库多 1 次磁盘读取，自然就慢了。
一句话总结：3 层 B + 树的实际 “收纳上限” 就是 2000 万，超了必加层变 4 层。
用大白话 + 极简计算讲清，1500 是工程实际近似值，核心来自 InnoDB 两个固定默认值的计算，无复杂公式：
核心前提（MySQL 天生固定，改不了）
非叶子节点的单页容量固定 16KB（=16384 字节），这是 InnoDB 默认数据页大小，所有层都一样；
非叶子节点的单个指引项（就是快递柜的「格子编号指引」）仅占≈10 字节，只存 2 样东西：主键值 + 下一层数据页的地址指针，无其他冗余内容，特别小。
1500 的计算逻辑（两步出结果）
理论最大值：16384 字节 ÷ 10 字节 / 个 ≈ 1638 个指引项；
实际工程值：不会存满，要留约 10% 空间给数据页管理信息（如页头 / 页尾的元数据），还要避免后续插入数据时频繁拆分页面，实际能用的约 1500 个，这是行业内统一的典型参考值（不是精确数，1400/1600 都算正常）。
一句话总结
16KB 固定页容量 ÷ 10 字节小指引项 = 理论约 1600 个，扣掉实际预留空间，最终取1500这个工程常用近似值。