MySQL缓存优化实战：巧用缓存削峰，提升查询效率与系统稳定性

使用Redis作为MySQL的前置缓存，将频繁查询且不常变动的数据缓存起来，是应对高并发查询、减轻数据库压力、提升系统稳定性的有效方法。

为什么需要缓存？

想象一下，你的网站首页每次打开都需要从MySQL数据库里重新计算用户信息、热门文章列表。平时人少的时候还好，一旦搞个促销活动，访问量突然暴增，成百上千的人同时刷新页面，MySQL数据库就像被一大堆人同时提问，很容易就忙不过来，响应变慢甚至崩溃。缓存的作用，就是提前把一些常见问题的答案（比如“首页热门文章是哪些”）记在一个更快的地方（比如内存里的Redis），下次有人再问，直接从这里拿答案，又快又省力，让MySQL能专心处理那些更复杂、真正需要它计算的新问题。

实战步骤：如何搭建缓存

第一步，确定需要缓存的数据。通常选那些读得多、写得少、变化不频繁的数据，比如网站配置、用户的基本资料（只要他不改名）、商品分类列表。第二步，选择缓存工具。Redis是最常用的，因为它速度快，支持多种数据结构。第三步，设计缓存逻辑。核心思路是：程序收到查询请求时，先去Redis里看看有没有缓存好的数据。如果有，就直接返回，完全不用打扰MySQL。如果没有，再去MySQL里查询，拿到结果后，顺手存一份到Redis里，并设置一个合理的过期时间（比如5分钟），方便下次使用。

一个简单的代码例子

以查询用户信息为例。假设我们有个函数叫`getUserInfo`，用户ID是123。下面是伪代码逻辑：

1. 先尝试从Redis读取键为`user:123`的数据。
2. 如果读到了，皆大欢喜，直接返回数据。
3. 如果没读到（缓存失效了），就去MySQL数据库执行`SELECT * FROM users WHERE id = 123`。
4. 从MySQL拿到数据后，用`SETEX user:123 300 用户数据JSON`这个命令，把数据存入Redis，并设置300秒（5分钟）后自动过期。
5. 最后把数据返回给用户。

这样，在5分钟内，所有查询用户123的请求都会直接从快速的Redis获取，MySQL的压力就小多了。

需要注意的坑

缓存虽好，但不能乱用。最大的问题是数据一致性问题：MySQL里的数据更新了（比如用户改了头像），但Redis里的缓存还是旧的。解决方法通常有两种：一是给缓存设置较短的过期时间，让旧数据尽快失效；二是在更新MySQL数据的同时，主动删除或更新对应的Redis缓存。另外，缓存不能无限使用，内存是有限的，要防止缓存太多数据把Redis撑爆。可以通过设置内存上限和使用LRU（最近最少使用）等淘汰策略来管理。

FAQ

问：所有数据都适合缓存吗？
答：不是。频繁变化的数据（如股票实时价格）缓存意义不大，因为很快就失效了。需要高度强一致性的数据（如账户余额）也要慎用缓存，或采用更复杂的同步策略。

问：缓存过期时间设置多长合适？
答：这没有固定答案，取决于业务。对实时性要求高的（如新闻排行榜），可以设短一点，比如30秒到1分钟。对变化很慢的数据（如城市列表），可以设很长，比如几小时甚至一天。需要根据业务特点调整和测试。

问：除了Redis，还有什么其他选择？
答：Memcached也是一个经典的纯内存缓存系统，在某些简单场景下与Redis类似。对于小型应用或特定框架，也可以考虑使用本地内存缓存（如Ehcache、Caffeine），但本地缓存无法在多个服务器间共享数据。

参考来源：本文经验基于常见的互联网后端架构实践，并参考了《Redis设计与实现》以及MySQL官方文档中关于查询优化的部分。