建议收藏：索引设计 缓存设计 | 零慢查询

▌ 技术引导
索引设计和缓存设计是两个看似简单却极易成为系统性能瓶颈的环节，我亲身经历过因索引选择错误导致的全表扫描灾难，也见过缓存策略不当引发的内存泄漏和数据不一致问题。索引不是越多越好，也不是越少越好，而是要根据查询模式、数据分布、写入频率等动态调整。例如，在MySQL中创建复合索引时，必须确保最左前缀原则，否则索引将无法被正确使用。缓存设计的关键在于存活策略和更新机制，Redis的TTL和Lua脚本是可靠的选择，但要避免缓存雪崩、穿透和并发更新问题。在实际项目中，我使用过Elasticsearch的字段类型优化、Memcached的Slab分配策略、以及本地缓存结合分布式缓存的混合方案，效果显著。如果能一次性把索引和缓存策略讲清楚，对于性能优化来说就是一场及时雨。

▌ 技术参考

一 索引设计的核心原则是基于查询频率和字段选择性来决定索引类型和字段顺序
在MySQL中，索引的创建要考虑字段的选择性。例如，在日志表中对时间字段加索引，选择性通常不高，但如果再加上唯一标识字段，可能形成高选择性的复合索引。创建索引时，我见过很多人盲目添加，导致索引过多、维护成本上升。正确的做法是按照查询模式分析，比如WHERE、JOIN、ORDER BY等条件，再结合字段数据类型，选择B-Tree、Hash、全文索引或空间索引。在创建复合索引时，必须确保字段顺序符合最左前缀原则，否则索引将失去作用。比如，如果有一个索引idx_user_age_city（user_id, age, city），那么查询user_id + age是有效的，但单独查询age或city则无法利用该索引。索引的选择性可以用COUNT(DISTINCT column)/COUNT()来衡量，数值越高，索引效果越好。

二 在Elasticsearch中，字段类型和映射设置直接影响索引效率和查询性能
Elasticsearch的字段映射必须精确，比如text字段不能用于精确匹配，而keyword字段更适合。我曾经在一个搜索系统中，因为错误地将ID字段设为text，导致聚合查询变得异常缓慢。正确的做法是为ID字段设置keyword类型，同时使用multi-field来支持全文检索。对于高写入量的场景，我推荐使用刷新间隔（refresh_interval）设置为-1，这样可以减少写入时的刷新频率，提升写入性能。但这样做的代价是查询时可能无法获取最新数据，所以需要根据业务需求权衡。对于嵌套字段，使用nested类型可以避免错误的查询结果，但会增加内存开销。我见过不少项目因为没有正确配置字段类型，导致索引占用空间过大，查询速度下降。

三 数据库索引的维护和优化需要结合执行计划和定期分析来实现
在PostgreSQL中，使用EXPLAIN ANALYZE可以查看查询执行计划，从而判断索引是否被有效使用。我曾在一个订单查询接口中发现，虽然建立了索引，但执行计划依然使用了全表扫描，后来通过分析发现是索引选择性太低。这时，我建议进行索引统计信息的更新，使用ANALYZE命令对相关表进行统计分析，这样查询优化器才能做出正确的索引选择。对于MySQL，可以使用SHOW INDEX FROM table来查看索引信息，结合EXPLAIN命令分析查询。如果插入数据频繁，索引的碎片化问题会日益严重，可以定期执行OPTIMIZE TABLE来重建索引，避免性能下降。此外，索引的覆盖扫描（Covering Index）是一个重要概念，如果查询能被索引覆盖，不需要回表，效率会大大提升。

四 缓存设计的关键在于合理的TTL和缓存淘汰策略，以及避免缓存雪崩
在Redis中，设置TTL（Time To Live）是一个基本但关键的操作，我见过很多系统因为TTL设置不当，导致缓存失效后请求直接打到数据库，造成数据库压力飙升。比如，设置TTL为30天，在某些业务场景中不够及时，导致缓存过期后数据无法及时更新。为了避免缓存雪崩，可以使用随机过期时间（随机值加在TTL上），而不是统一时间。此外，对于热点数据，使用本地缓存（如Guava Cache）配合分布式缓存（如Redis）是常见策略。我曾经在某个电商系统中遇到缓存穿透问题，解决方案是使用布隆过滤器，预先判断数据是否存在，从而减少对数据库的无效查询。不过布隆过滤器的误判率需要合理设置，否则会带来额外的验证开销。

五 多级缓存策略在高并发系统中能有效降低延迟和数据库压力
我见过很多大型系统采用本地缓存+分布式缓存+数据库的三层次结构。例如，使用Guava Cache作为本地缓存，用于高频访问、低延迟的数据，而Redis作为分布式缓存，用于跨节点共享的数据。数据库作为最终存储，主要处理持久化和数据一致性。在实际操作中，本地缓存的大小需要根据内存和业务需求动态调整，一般设置为10MB到100MB之间，太大可能影响GC效率。分布式缓存的配置可以使用Redis的集群模式，确保高可用和数据分片。对于缓存更新，我推荐使用缓存失效+预加载的策略，比如在数据变更时主动删除缓存，并在请求入口进行预加载。这种做法在某些高并发场景中效果非常明显，但需要处理好分布式缓存的同步问题。

六 缓存穿透、雪崩和击穿问题需要不同的解决方案，不能一刀切
缓存穿透指的是查询一个不存在的数据，导致频繁访问数据库。解决方法包括使用布隆过滤器或空值缓存。比如，当查询一个不存在的ID时，将null值缓存一段时间，避免重复查询。雪崩问题是指大量缓存同时失效，导致请求全部落到数据库。解决方法是给每个缓存项设置随机的过期时间，或在缓存失效时触发异步刷新。击穿问题则是针对热点数据的缓存失效后，大量请求同时访问数据库。解决方法是使用互斥锁或热点数据预加载，比如在Redis中使用SETNX命令确保只有一个线程去加载数据。在实际中，我结合了布隆过滤器和互斥锁，取得了较好的效果，但需要根据业务场景微调。

七 使用Redis的Lua脚本可以原子化操作，避免缓存更新的并发问题
在需要对缓存进行复杂操作的场景下，Lua脚本是一个非常有效的工具。比如，在更新某个缓存项时，可以利用Redis的EVAL命令执行脚本，确保多个操作在同一个事务中完成。我见过一个订单状态更新的场景，由于多个线程同时更新同一个缓存键，导致数据不一致。这时，我通过Lua脚本实现了原子操作，避免了竞态条件。此外，使用Redis的Pipeline功能也能减少网络延迟，批量发送多个命令。需要特别注意的是，Lua脚本执行时间不能太长，否则会影响Redis的响应速度，导致阻塞。因此，在编写脚本时要尽量精简，避免复杂的逻辑和长时间的计算。

八 在分布式系统中，缓存一致性需要额外的处理机制，比如消息队列或更新延迟
缓存和数据库之间的数据一致性是一个长期存在的难题。我见过很多项目使用消息队列来处理缓存更新，例如当数据库写入成功后，将更新事件发送到Kafka或RabbitMQ，由消费者异步更新缓存。这种方法能有效降低系统耦合度，但也带来了更新延迟的问题。在实际中，我采用的是缓存失效+预加载的策略，当数据库发生变更时，直接删除缓存，并在后续读请求中触发数据更新。这种做法虽然不能保证实时一致性，但在大多数场景中足够使用。对于强一致性要求的业务，可能需要结合数据库的事务机制，比如在数据库事务提交后才更新缓存，但这样可能会增加系统复杂度。

九 使用本地缓存时，需要考虑缓存的更新策略和内存管理，避免资源浪费
本地缓存框架如Guava Cache或Caffeine提供了多种缓存策略，比如基于大小的淘汰（maximumSize）、基于时间的淘汰（expireAfterWrite）等。我曾在一个微服务中使用Guava Cache，但因为没有设置合适的大小限制，导致内存溢出。后来改为使用Caffeine，它基于Window TinyLFU算法，能更高效地管理缓存。在配置时，我建议根据业务需求调整缓存大小和淘汰策略，比如对于订单详情，可以设置expireAfterWrite为5分钟，同时限制缓存条目数为10000。此外，需要注意缓存的并发策略，比如使用ConcurrentHashMap来确保线程安全，或者使用缓存的自动加载机制，避免缓存空洞问题。

十 在高并发场景中，缓存的读写分离和穿透控制是必须的，不能依赖单一缓存机制
我曾在一个直播平台中使用Redis作为缓存，但因为直播内容更新频繁，导致缓存大量失效。为了应对这种情况，我采用了读写分离的策略，将热点内容缓存到本地，非热点内容缓存到Redis。这种做法虽然增加了系统复杂度，但能有效减少数据库压力。对于缓存穿透，我使用了空值缓存，当查询不存在的数据时，将其缓存为null，并设置较短的TTL，比如1分钟。这样既能防止数据库被频繁访问，又能保证缓存的有效性。此外，我推荐使用分布式锁来处理缓存更新，确保只有一个线程在缓存失效后加载数据，避免多个线程重复操作。

十一 索引的分区策略和压缩方式对存储空间和查询性能有显著影响
在使用MySQL时，我曾针对大表进行过分区操作，比如按时间范围进行范围分区，这样可以减少扫描的数据量，提升查询效率。同时，使用InnoDB的压缩表（COMPRESS=ZLIB）可以显著降低存储空间，但会增加CPU的开销。因此，在选择压缩方式时要根据业务需求权衡。对于读写频繁的表，压缩可能不是最优选择，但对于只读或冷数据，压缩能带来明显的存储收益。我见过不少项目因为没有正确配置索引的分区和压缩策略，导致索引占用空间过大，甚至影响到数据库的整体性能。因此，在做索引设计时，必须结合存储成本和查询效率综合判断。

十二 在Elasticsearch中，字段的分词方式和索引方式决定了搜索效率和准确性
我曾在一个搜索系统中因为字段的分词方式不正确，导致搜索结果不准确，用户反馈差。后来通过调整字段的analyzer配置，使用ik_max_word分词器，提升了中文搜索的准确性。对于需要精确匹配的字段，比如状态码或分类ID，应该使用keyword类型，而不是text类型。此外，在索引创建时，可以指定字段的索引方式，比如not_analyzed，以避免不必要的分词。我见过很多项目因为没有正确设置字段的映射和分析器，导致查询性能低下，甚至需要全表扫描。因此，在索引设计时，要结合字段的用途和搜索需求，做出精准的配置。

十三 在索引设计中，避免过度索引和索引碎片化，保持索引的简洁性和有效性
我曾经在一个订单表中创建了多个索引，结果发现索引维护成本过高，写入性能下降明显。后来通过分析查询日志，剔除了部分低频查询字段的索引，反而提升了整体性能。索引碎片化是另一个常见问题，尤其是在频繁更新的表中，索引可能会变得碎片化，影响查询效率。在MySQL中，可以使用OPTIMIZE TABLE命令来重建索引，减少碎片。对于PostgreSQL，使用VACUUM FULL来清理和重建表，也能改善索引性能。我见过不少项目因为索引碎片化，导致查询响应时间翻倍，最终不得不进行大规模重建。

十四 在缓存设计中，使用内存预分配和Slab机制可以提升性能和稳定性
我曾使用Memcached作为缓存，但因为内存碎片化严重，导致缓存命中率下降。后来改用Redis，发现其Slab机制能更有效地管理内存，减少碎片。在配置Memcached时，可以预分配内存，避免碎片化带来的性能损耗。此外，使用Redis的内存淘汰策略（如allkeys-lru）可以有效管理内存，确保缓存不会占用过多资源。我见过很多项目因为没有正确设置内存限制和淘汰策略，导致缓存占用内存过大，甚至引发OOM（Out Of Memory）错误。因此，在缓存配置中，需要根据业务需求合理设置内存上限和淘汰规则。

十五 使用缓存预热和冷启动策略可以减少系统延迟和缓存未命中率
我曾在一个用户系统中遇到缓存冷启动问题，系统刚启动时大量查询落在数据库上，影响用户体验。后来通过在系统启动时预加载常用数据到缓存，解决了这个问题。预加载可以通过定时任务或异步处理来实现，例如在应用启动后，使用定时任务加载热门用户信息到Redis中。对于冷启动场景，我推荐使用本地缓存作为过渡，确保系统在启动初期也能快速响应。此外，缓存预热还可以结合业务高峰时段进行，比如在促销活动前加载相关商品数据。这样能有效降低高峰期的数据库压力，提升系统稳定性。