查询慢主因是未命中索引而非数据量大；WHERE字段无索引将触发全表扫描，EXPLAIN中type为ALL即警告；避免函数操作、合理使用ORDER BY+LIMIT分页、JOIN时小表驱动大表并确保连接字段类型一致且有索引。
WHERE 条件没走索引，查 100 万行像查 100 行一样慢
不是数据量大就一定慢，是查询没命中索引才真卡。MySQL/PostgreSQL 都会先看 WHERE 字段有没有可用索引，没有就全表扫描——哪怕你只想要 1 条。
- 用
EXPLAIN看执行计划，重点盯type列：出现ALL就是全表扫，range或ref才算走索引 -
WHERE里别对字段做函数操作，比如WHERE YEAR(created_at) = 2024会让索引失效；改成WHERE created_at >= '2024-01-01' AND created_at - 联合索引要注意最左前缀：建了
(user_id, status, created_at)，那WHERE user_id = 123 AND status = 'active'能用，但WHERE status = 'active'就用不上
SELECT * 拉太多字段，网络和内存都扛不住
大数据量下，传输和序列化开销可能比 SQL 执行本身还重。尤其当字段含 TEXT、JSON 或长字符串时，一条记录几百 KB 很常见。
- 只查真正需要的字段，明确写出列名，别偷懒写
SELECT * - 避免在
SELECT里用子查询或函数（如CONCAT(name, '-', id)），这些会在每行上重复计算 - 如果前端只需要 ID 和标题，后端却查了 20 个字段+3 个 JSON 字段，IO 和 GC 压力会直线上升
OFFSET 越大越慢，分页查到第 1000 页直接超时
LIMIT 10 OFFSET 10000 不是跳过前 1 万条再取 10 条，而是让数据库先找出前 10010 条，再丢掉前 10000 条——数据越往后，成本越高。
- 改用游标分页：
WHERE id > 12345 ORDER BY id LIMIT 10，靠主键或时间戳做“断点续查” - 如果必须用
OFFSET，确保ORDER BY字段有索引，且和WHERE条件能组合使用（比如WHERE status = 'done' ORDER BY created_at） - 超过 10 万级偏移量，基本该考虑归档旧数据或加缓存层了，硬扛不现实
JOIN 多张大表，执行计划崩了都不知道怎么救
三张百万级表一 JOIN，如果没控制好驱动表顺序和连接字段索引，很容易触发 Using temporary; Using filesort，甚至爆内存。
- 用
EXPLAIN看rows预估行数，如果某张表预估几十万，而它又是被驱动表，大概率出问题 - 小表驱动大表：把过滤后只剩几百行的表放
FROM，大表放JOIN右侧；MySQL 5.7+ 会自动优化，但别完全依赖 -
ON条件字段类型要严格一致，比如INT对VARCHAR会导致隐式转换，索引失效
最常被忽略的一点：索引不是建了就生效，得看查询条件是否匹配它的结构和顺序；而 EXPLAIN 输出里的 key_len 和 Extra 字段，才是真正告诉你“到底用了索引哪几列”的证据。
