PHP主流架构怎么优化查询性能_索引与缓存【方法】

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() 方法，否则上线后出问题很难定位。