没索引时查询慢是因为数据库需全表扫描，EXPLAIN显示type:ALL或Seq Scan且key为NULL；应建单列或联合索引，注意字段顺序、类型匹配和区分度，并权衡写入开销。
为什么 WHERE 条件字段没加索引，查询就慢得像卡住
因为 MySQL、PostgreSQL 等主流数据库默认不会全表扫描优化——没索引时，哪怕只查 1 行，也可能扫几十万行数据。执行计划里出现 type: ALL 或 Seq Scan 就是典型信号。
- 先看执行计划：
EXPLAIN SELECT * FROM orders WHERE user_id = 123;，重点盯key列是否为NULL - 单字段查询优先建单列索引：
CREATE INDEX idx_orders_user_id ON orders(user_id); - 注意隐式类型转换：比如
user_id是BIGINT，但查询写成WHERE user_id = '123'，索引会失效 - 字符串字段用
LIKE时，只有前缀匹配（LIKE 'abc%'）能走索引，LIKE '%abc'不行
ORDER BY 很慢？别只盯着排序字段加索引
单独给 ORDER BY 字段建索引往往没用，数据库要先找数据再排序，两步操作无法合并。真正有效的是把「过滤 + 排序」字段组合起来建联合索引。
- 例如：
SELECT * FROM logs WHERE level = 'ERROR' ORDER BY created_at DESC;，应该建INDEX idx_logs_level_created ON logs(level, created_at) - 顺序很重要：等值条件（
=）字段放前面，范围/排序字段放后面；level是等值，created_at是范围/排序，所以不能反过来 - 如果还有
LIMIT 10，联合索引能直接定位前 10 行，避免临时表和文件排序（Using filesort） - PostgreSQL 对
DESC支持更好，MySQL 8.0+ 才支持降序索引，老版本一律按升序存，ORDER BY ... DESC可能无法利用索引
联合索引的字段顺序不是随便排的
字段顺序决定索引能否被复用。数据库按 B+ 树从左到右匹配，一旦遇到范围查询（>、BETWEEN、LIKE 'abc%'），右边字段就失效了。
- 错误示例：
INDEX idx_a_b_c (a, b, c)，查询WHERE a = 1 AND c = 3——c用不上 - 正确思路：高频等值字段优先，比如用户表常按
status和created_at查，则(status, created_at)比反过来更实用 - 区分度高的字段不一定放最前——比如
is_deleted TINYINT只有 0/1，即使放第一，也大概率导致索引选择性差，优化器可能干脆不用 - 用
SHOW INDEX FROM table_name查Cardinality值，粗略判断字段区分度（但别全信，它只是采样估算）
什么时候不该加索引
索引不是免费的。写多读少、字段更新频繁、或根本查不到几行的表，加索引反而拖慢整体性能。
- 写入密集场景（如日志流水表）：每条
INSERT都要同步更新所有相关索引，索引越多，写越慢 - 低基数布尔字段（如
is_active）：除非配合其他条件构成联合索引，否则单独建索引基本无效，优化器通常跳过 - 大文本字段（
TEXT、JSON）：MySQL 不支持对全文本建普通索引，要用FULLTEXT或生成列 + 普通索引 - 小表（比如
status_codes只有 10 行）：全表扫描比走索引还快，加了也白加
最常被忽略的一点：索引本身要占磁盘和内存，线上服务内存紧张时，过多索引会让 buffer pool 压力陡增，间接拖慢所有查询。加之前，先问自己——这个查询真跑得够慢、够频繁、够关键吗？
