加索引仍慢的主因是回表、filesort、临时表、索引失效或数据量过大；需结合explain format=json分析rows、filtered和extra，优化联合索引顺序与覆盖度，并删减低效索引。
为什么加了索引，EXPLAIN 显示用了，但查询还是慢？
常见错觉：只要 EXPLAIN 的 type 是 ref 或 range，就代表快。实际可能卡在回表、排序、临时表或数据量膨胀上。
- 如果
SELECT *且索引不覆盖查询字段，InnoDB 会根据主键回表查完整行——10万行 = 10万次随机磁盘 I/O -
ORDER BY字段没包含在联合索引最右位置，或用了filesort，大数据量时直接拖垮 - 索引列上有函数或隐式转换，比如
WHERE YEAR(created_at) = 2024，索引失效 - 用
LIKE '%abc'开头，B+ 树无法利用索引做范围扫描
实操建议：先跑 EXPLAIN FORMAT=JSON，重点看 rows（预估扫描行数）、filtered（过滤率）、Extra 里有没有 Using filesort 或 Using temporary。
WHERE 条件顺序和联合索引字段顺序到底谁重要？
MySQL 不关心 WHERE 子句里条件写的先后，只认联合索引的定义顺序。但人容易写反，导致索引“部分失效”。
- 建了
INDEX (user_id, status, created_at)，那么WHERE user_id = ? AND status = ?能用，但WHERE status = ? AND created_at > ?完全用不上 - 等值条件（
=）必须放最左，范围条件（>,BETWEEN）后面字段无法走索引——WHERE a = 1 AND b > 2 AND c = 3中，c就不会被索引命中 - 区分度高的字段往前放，比如
user_id（百万级唯一值）比status（通常就 3–5 个枚举值）更适合放索引首位
示例：查“某用户最近 10 条待处理订单”，别建 (status, created_at, user_id)，而应建 (user_id, status, created_at)，再配合 ORDER BY created_at DESC LIMIT 10。
立即学习“PHP免费学习笔记（深入）”；
PHP 层怎么避免“一次查全，PHP 循环过滤”这种低效操作？
典型场景：SQL 查出 5000 行，PHP 用 foreach 遍历，再用 if ($row['status'] !== 'done') 筛一遍。本质是把数据库该干的事甩给了 PHP。
- 数据库筛选永远比 PHP 内存遍历快——尤其涉及字符串比较、时间计算、关联字段判断时
- 不要在 PHP 里拼
IN列表超过 1000 项，改用临时表或分批查；更别用array_filter()替代WHERE - 注意 PDO 默认是
PDO::FETCH_BOTH，取 10 万行会多占一倍内存，明确设为PDO::FETCH_ASSOC - 大结果集别用
fetchAll()一次性加载，改用fetch()迭代，或游标式查询（MYSQLI_USE_RESULT）
错误写法：$rows = $pdo->query("SELECT * FROM orders")->fetchAll(); foreach ($rows as $r) { if ($r['amount'] > 1000) {...} } → 应该让 SQL 做掉 WHERE amount > 1000。
什么时候该删索引，而不是加索引？
索引不是越多越好。写多读少的表，或长期不用的索引，反而拖慢 INSERT/UPDATE/DELETE，还吃内存和磁盘空间。
- 用
SELECT * FROM sys.schema_unused_indexes（MySQL 8.0+）或performance_schema.table_io_waits_summary_by_index_usage找“零命中”索引 - 单表索引总数建议控制在 5–7 个以内；超过这个数，每增一个都要问：这个查询频次够不够高？有没有更优的联合索引能覆盖它？
-
UNIQUE索引在业务无强唯一性要求时，慎用——唯一性校验有开销，且一旦插入冲突，应用层处理比普通索引失败更重 - 监控
Innodb_buffer_pool_reads和Innodb_buffer_pool_read_requests比值，若长期 > 1%，说明索引/数据太大，Buffer Pool 装不下，得考虑归档旧数据而非硬加索引
真正卡点往往不在“怎么加”，而在“哪些可以砍”。上线前跑一周慢查日志，按 Query_time 和 Rows_examined 排序，优先优化那几个“高频 + 高扫描”的 SQL，而不是给所有 WHERE 都配索引。
