多列索引应建在查询条件「成组出现」的字段上；若WHERE中常同时等值匹配A、B、C，则建(A,B,C)索引优于三个单列索引，因MySQL一次仅用一个索引，且需遵循最左前缀原则。
多列索引到底该不该建？看查询条件是否「成组出现」
直接结论：如果 WHERE 子句里经常同时用到 A、B、C 三个字段做等值匹配（比如 WHERE status = 'active' AND user_id = 123 AND created_at > '2025-01-01'），优先建一个 (status, user_id, created_at) 多列索引；而不是给每个字段单独建单列索引。
原因很简单：MySQL 一次查询最多只用一个索引。三个单列索引摆在那儿，优化器只能挑一个“区分度最高”的用（比如 user_id），剩下两个字段就得全表扫描或临时过滤——白建了两个。
- ✅ 适合建多列索引的典型场景：
SELECT * FROM orders WHERE shop_id = 5 AND status = 'paid' ORDER BY created_at DESC - ❌ 不适合建多列索引的场景：
WHERE category = 'book' OR author LIKE '%mysql%'（OR+LIKE前导通配符，基本无法走索引） - ⚠️ 注意：字段顺序不能乱。多列索引
(a,b,c)能加速WHERE a=1 AND b=2，但对WHERE b=2 AND c=3完全无效
单列索引不是没用，而是用在「独立高频访问」的字段上
单列索引的价值不在联合查询，而在「单点穿透」：比如用户登录查 username、后台按 deleted_at IS NULL 筛有效数据、分页查 id > 1000。
这类操作不依赖其他字段，单列索引就能直达目标行，且占用空间小、维护成本低。盲目替换成多列索引反而浪费资源。
- ✅ 值得单独建单列索引的字段：
id（主键）、email（唯一性校验）、token（API 鉴权）、state（状态枚举，高区分度） - ❌ 别为低区分度字段单独建索引：
gender（只有 'm'/'f'）、is_deleted（大量重复值），B-Tree 效率极低，还拖慢写入 - ? 小技巧：用
SELECT COUNT(DISTINCT col)/COUNT(*) FROM table算区分度，> 0.1 才值得索引
最左前缀原则不是玄学，是 B-Tree 查找路径的硬约束
多列索引本质是一棵按字段顺序排序的 B-Tree。索引 (a,b,c) 的叶子节点，先按 a 排，a 相同再按 b 排，b 也相同才按 c 排。所以查询必须从左开始“连续匹配”。
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
常见失效情况：
-
WHERE a = 1 AND c = 3→ 只能用上a，c无法跳过b直接定位 -
WHERE b = 2 AND c = 3→ 完全不走索引（没提供最左列a） -
WHERE a = 1 AND b > 10 AND c = 3→a和b有效，c失效（范围查询后，右侧列索引终止）
验证方法永远是 EXPLAIN，重点看 key 和 key_len 是否符合预期。
别迷信“全字段覆盖”，小心索引膨胀和更新拖累
多列索引越宽，磁盘占用越大，写入时要维护的索引页越多，INSERT/UPDATE/DELETE 性能下降越明显。尤其当包含大字段（如 TEXT 前缀过长）、时间戳、JSON 字段时，代价更高。
- ✅ 合理做法：只把真正参与
WHERE/ORDER BY/GROUP BY的字段放进多列索引；SELECT列不用塞进去（除非想实现覆盖索引） - ✅ 覆盖索引加分项：如果查询只需返回索引列本身（如
SELECT user_id, status FROM orders WHERE shop_id = 5），可加INCLUDE（MySQL 8.0+ 支持函数索引或冗余列） - ⚠️ 高危操作：为“以防万一”把 5 个字段全塞进一个索引，结果发现
ALTER TABLE卡住 20 分钟，线上写入堆积
真正难的不是建索引，是判断哪些查询模式真实高频、哪些只是开发时随手写的测试 SQL。上线前务必用生产流量抽样分析 slow_log 或 performance_schema，别靠猜。
