MySQL索引失效典型场景包括：WHERE条件对字段使用函数、隐式类型转换、OR连接非索引列、LIKE以%开头、索引列参与计算或为空值判断；应避免全表扫描，优化为范围查询并合理使用EXPLAIN分析。
MySQL 索引失效的典型场景有哪些
很多查询变慢不是因为没建索引，而是索引根本没被用上。执行 EXPLAIN 后发现 type 是 ALL 或 index，基本就是全表扫描了。
常见诱因包括：
-
WHERE条件中对字段用了函数，比如WHERE YEAR(created_at) = 2025→ 改成WHERE created_at >= '2025-01-01' AND created_at -
隐式类型转换，如
WHERE user_id = '123'（user_id是INT）→ 字符串强制转整数可能跳过索引 - 使用
LIKE以通配符开头：WHERE name LIKE '%abc'→ 无法利用 B+ 树索引，考虑全文索引或倒排表 - 联合索引未遵循最左前缀原则，比如索引是
(a, b, c)，但查询只用了b和c→ 不会命中
PHP-FPM + MySQL 架构下该用哪种缓存策略
不是所有数据都适合缓存，也不是缓存越深越好。关键看读写比、一致性要求和更新频率。
推荐分层组合：
-
应用层缓存：用
Redis缓存高频、低更新的聚合结果，比如首页推荐列表。避免缓存单行记录（如user:123），容易和 DB 脱节 -
查询结果缓存：慎用 MySQL 自带的
query_cache（已从 MySQL 8.0 移除），改用应用层控制，比如用Redis::setex()存序列化后的数组，并带业务键前缀（如search:tag:php:page:1） -
ORM 层缓存：Laravel 的
Cache::remember()或 Doctrine 的ResultCache可封装查询逻辑，但注意 TTL 设置要短于业务容忍脏读时间
特别注意：写操作后必须主动失效相关缓存，而不是等过期。例如更新文章后，删掉 article:{$id} 和 category:{$cat_id}:list 两个 key。
如何验证索引是否真的提升了查询速度
不能只看 EXPLAIN 的 rows 估算值，得测真实执行时间与 IO 开销。
SELECT SQL_NO_CACHE COUNT(*) FROM orders WHERE status = 'paid' AND created_at > '2025-06-01';
加 SQL_NO_CACHE（MySQL 5.7）或关闭 query_cache_type，避免缓存干扰。同时观察：
- 执行前后
SHOW STATUS LIKE 'Handler_read%';中Handler_read_next是否大幅下降 - 用
pt-query-digest分析慢日志，确认该 SQL 的平均响应时间是否从 320ms 降到 12ms - 在高并发压测时（如
ab -n 1000 -c 50），看 CPU 和 InnoDB buffer pool 命中率（show engine innodb status里的Buffer pool hit rate）
Redis 缓存穿透与雪崩怎么防
这是 PHP 服务连 Redis 时最容易翻车的两个点，尤其在商品详情、用户资料类接
口。
缓存穿透（查不到还反复打 DB）：
- 对空结果也缓存，比如
Redis::setex('user:999999', 60, 'null')，但值要可识别（别用null，用empty或自定义标记） - 请求前先查布隆过滤器（Bloom Filter），用
redis-bloom模块或客户端预加载白名单
缓存雪崩（大量 key 同时过期）：
- 设置随机 TTL，比如基础 3600 秒，再加
rand(1, 300)秒 - 关键数据用永不过期 + 主动刷新（后台定时任务查 DB 更新 Redis）
- 加互斥锁：首次未命中时，用
SETNX cache:key:123 lock 30抢锁，抢到的去查 DB 并回填，其余等待 100ms 后重试
这些逻辑别堆在控制器里，抽成独立的 CacheService::getWithFallback() 方法，否则上线后出问题很难定位。
