LIKE '%关键词%' 慢是因为全表扫描导致索引失效；应改用前缀匹配、全文索引或函数提取等优化方案。
WHERE 条件里用 LIKE '%关键词%' 为什么慢得像卡住
因为全表扫描不可避免，索引完全失效。哪怕字段上有 INDEX，只要左边带通配符（%），MySQL 和 PostgreSQL 都没法用 B-Tree 索引做范围查找。
常见错误现象：EXPLAIN 显示 type: ALL，rows 接近全表记录数，查询耗时从毫秒跳到秒级，尤其在 orders 或 products 表超百万行时更明显。
- 真要模糊查商品名，优先改用
LIKE '关键词%'（前缀匹配），确保能走索引 - 必须中间/后缀匹配？考虑加
fulltext索引 +MATCH ... AGAINST（MySQL）或to_tsvector（PostgreSQL） - 别在订单号字段上写
LIKE '%202410%'—— 订单号应设计为固定格式，用BETWEEN或函数提取（如LEFT(order_no, 6) = '202410'）更高效
JOIN 多张表时，ORDER BY 突然变慢
不是 JOIN 本身慢，而是排序字段不在驱动表（通常是第一个 FROM 表）的索引里，导致 MySQL 被迫用 filesort，临时磁盘排序拖垮性能。
典型场景：查「某用户最近 10 笔订单 + 商品名称 + 店铺名」，写成 SELECT ... FROM orders o JOIN items i ON o.id = i.order_id JOIN shops s ON i.shop_id = s.id ORDER BY o.created_at DESC LIMIT 10 —— 如果 orders.created_at 没索引，或 orders 不是驱动表，就崩。
- 先确认驱动表（
EXPLAIN的第一行），给它的排序字段建索引，比如ALTER TABLE orders ADD INDEX idx_user_created (user_id, created_at DESC) - 避免在
JOIN后的非驱动表字段上ORDER BY，例如ORDER BY s.name基本等于放弃索引优化 - 如果必须按关联表字段排序，考虑把关键数据冗余到主表（如订单表存
shop_name），用空间换时间
COUNT(*) 在大订单表里执行几秒，但加了 WHERE 反而更慢
因为 MySQL 对 COUNT(*) 有优化（InnoDB 维护了近似行数），但加上 WHERE 后必须真实扫描满足条件的行，而你的条件可能没走索引，或者索引区分度太低（比如 status IN ('paid', 'shipped') 占 95% 行数）。
电商常见陷阱：统计「昨日待发货订单数」写成 COUNT(*) FROM orders WHERE DATE(created_at) = '2024-10-10' —— DATE() 函数让索引失效。
- 改用范围查询：
created_at >= '2024-10-10 00:00:00' AND created_at - 状态类字段加索引前，先看
SELECT COUNT(*), status FROM orders GROUP BY status，如果某个值占比超 20%，这个索引效果很有限 - 实时性要求不高的统计（如后台报表），别直接
COUNT(*)，用定时任务把结果写进汇总表
分页查订单列表，LIMIT 10000, 20 越往后越卡
MySQL 不会跳过前 10000 行再取 20 行，而是先查出 10020 行，再丢弃前 10000 行 —— 数据量越大，丢弃成本越高。
用户翻到第 500 页时，响应时间可能从 50ms 涨到 2s+，DB CPU 直接拉满。
- 用游标分页替代偏移分页：上次查到的最后一条记录的
id或created_at作为下一页起点，例如WHERE id > 12345 ORDER BY id LIMIT 20 - 如果必须支持任意页码（比如 SEO 或管理后台），给
ORDER BY字段加联合索引，并限制最大页码（如只允许查前 100 页） - 别在分页 SQL 里
SELECT *，只查前端真正需要的字段，减少网络和内存开销
最麻烦的其实是「既要模糊搜、又要多表联查、还要按关联字段排序、最后还得分页」—— 这种组合拳，单靠 SQL 优化往往不够，得提前在应用层拆解逻辑，或者引入 Elasticsearch 做异构查询。
