索引失效场景剖析：为什么查询还是慢？

在绝大多数线上故障中，慢查询并不是因为缺少索引，而是索引在使用过程中“静默失效”。最常见的失效场景包括：对索引列使用函数运算，例如 `WHERE DATE(create_time) = '2024-01-01'`，这会让数据库无法利用 `idx_create_time`，必须全表扫描；隐式类型转换同样致命，比如 `WHERE phone = 13800138000`，当 phone 字段是字符串类型时，数据库会将索引列强制转换为数值，导致索引失效；还有前导模糊查询 `LIKE '%keyword'`，由于无法确定匹配起点，B+树无法进行范围定位。此外，联合索引中不遵守“最左前缀”规则，例如索引为 `(a,b,c)` 却只查询 `b` 和 `c`，索引也会被跳过。要想真正利用索引，必须通过 `EXPLAIN` 查看执行计划，关注 `type` 是否为 `ref` 或 `range`，`key` 是否实际使用，以及 `rows` 估算扫描行数。只有消除隐式转换和函数包裹，并保持条件列独立，索引才能发挥其毫秒级定位能力。

复合索引与覆盖索引：从B+树结构看检索效率

复合索引的设计本质上是构建一棵按多列排序的B+树。例如索引 `(user_id, status, created_at)`，数据先按 `user_id` 排序，同一 `user_id` 下再按 `status` 排序，最后按 `created_at` 排序。当查询同时包含这三个等值条件时，B+树可以精确定位到目标叶子节点，避免回表。更激进的做法是覆盖索引：将查询所需的全部字段都放入索引中，例如 `SELECT order_id, amount FROM orders WHERE status = 1`，如果建立 `(status, order_id, amount)` 索引，那么所有数据都能从索引叶子节点直接获取，完全跳过聚簇索引的回表操作。回表意味着随机I/O，在机械硬盘或高并发场景下，一次回表可能增加 0.5~1ms 延迟，而覆盖索引能将延迟降低一个数量级。但复合索引并非越多越好，每增加一个索引都会拖慢写入速度并消耗存储空间。实践中应遵循“高区分度列前置”和“查询过滤最频繁列优先”的原则，同时使用 `IN` 或 `BETWEEN` 时注意范围列会中断后续排序，因此范围条件后的字段通常不适合继续放在同一复合索引中。

缓存策略分层：从Redis到本地缓存的落地实践

索引优化存在物理极限：当单表数据量达到千万级，就算走索引，磁盘I/O和网络传输仍需数毫秒；若访问热点集中，缓存便成为比索引更“快”的一层。分层缓存通常从最靠近应用的内存开始：本地缓存（如 `Caffeine` 或 `Guava Cache`）读取延迟为纳秒级，适合存放配置信息、用户会话等极热数据；第二层是分布式缓存（如 `Redis`），内存网络访问约 0.1~1ms，用于共享热点数据，如商品详情、排行榜等；第三层才是数据库。落地时要避免缓存穿透、击穿和雪崩：穿透可通过布隆过滤器拦截不存在的 key；击穿可通过对热点 key 加互斥锁或设置逻辑过期时间；雪崩则要给缓存过期时间增加随机抖动，并设置多级容灾。此外，缓存粒度值得精心设计：过细会导致大量 `get` 请求，过粗会浪费内存且更新困难。常用策略是“对象级缓存 + 关联查询结果缓存”相结合，同时为缓存设置合理的 TTL，让数据自然过期来兜底。一个成熟的系统往往先查本地缓存，未命中再查 Redis，仍然未命中才查数据库，并将结果逐级回填，从而将平均延迟从 5ms 压缩到 1ms 以下。

缓存与数据库的一致性方案：延迟优化后的可靠性保障

当数据库旁放置缓存后，最棘手的问题不再是速度，而是数据一致性。常见的错误做法是先更新数据库，再删除缓存，但如果删除缓存失败，下一次请求会读到旧值；而“先删缓存，再更新数据库”则存在并发窗口：线程A删除缓存后，线程B读取旧值并回填，随后线程A更新数据库，导致缓存长期为脏数据。业界最稳妥的方案是“Cache Aside”加“延迟双删”：先更新数据库，然后删除缓存，等待几百毫秒后再删除一次，以消除并发期间的旧回填。更进一步，可以使用订阅数据库 binlog（如 Canal）异步删除对应缓存，保证最终一致性。对于强一致性要求极高的场景，则需要放弃缓存，直接读数据库；或者引入分布式锁，让同一 key 的读写串行化。另一个实用技巧是“版本号”设计：在业务数据中附带递增版本号，缓存存储 `value` 和 `version`，更新时对比版本，低版本数据不会被回填，从而消除竞态条件。实践中应明确一致性容忍度：大多数读多写少业务允许秒级延迟，采用异步删除加 TTL 即可；而金融交易类则尽量避免缓存中间态，或者将缓存改为“只读副本”并强制走主库写、延迟副本读。归根结底，缓存一致性方案必须结合业务场景权衡，不能为了速度牺牲正确性，也不能因为过度设计而引入过高的复杂度。