1. 先搞明白它们到底是什么核心定位与底层原理1.1 MySQL关系型数据库的“绝对核心”MySQL 是一个关系型数据库管理系统核心价值就是把数据按照“表”的结构组织起来表与表之间通过主键、外键等关系关联。它解决的核心问题是持久化存储和高效查询。你存进去的数据只要不主动删除关掉电源再开机数据还在。底层原理层面最关键的是它的存储引擎架构。默认的 InnoDB 引擎用 B 树作为索引结构。为什么是 B 树而不是二叉搜索树或者哈希表因为 B 树是“矮胖子”三层就能支撑上千万条数据。每层节点存储多个 key磁盘 IO 次数被压缩到 3 次左右。哈希表虽然单点查询 O(1)但它做不了范围查询所以 MySQL 默认索引不选哈希。二叉搜索树在数据量大了以后会退化成链表树的高度太高磁盘 IO 次数太多不可接受。InnoDB 还通过 redo log 和 undo log 保证崩溃恢复和事务回滚能力。redo log 是物理日志记录“页改成了什么样”用于崩溃后重放undo log 是逻辑日志记录“原来是什么样”用于事务回滚。再加上 buffer pool 把热数据缓存在内存里MySQL 才能在高并发下扛住压力。你把 MySQL 理解为“把数据稳妥地写在磁盘上同时用内存加速读取”的系统这个定位就抓住了。1.2 Redis基于内存的“速度机器”Redis 是一个基于内存的键值存储系统官方定位是 in-memory data structure store。它的核心价值是在毫秒甚至微秒级别完成读写操作。因为它所有数据默认都存储在内存里不落磁盘所以天然比磁盘上的 MySQL 快几个数量级。Redis 的底层数据结构远比表面看到的五种基础类型要复杂。String 底层是 SDSSimple Dynamic String避免了 C 字符串的缓冲区溢出问题同时能 O(1) 获取长度List 底层是 quicklist是双向链表和压缩列表的混合体兼顾了两端插入的效率和内存占用Hash 在数据量小的时候用 ziplist 压缩存储数据量大了以后转成 hashtableSet 底层是 intset 或 hashtableZSet 底层是跳表skip list。跳表这个结构值得多说一句它其实是用“多层链表 空间换时间”的方式实现了类似二分查找的效果插入、删除、查找都是 O(logN)而且实现比平衡树简单得多Redis 作者选它不选红黑树是从工程角度做的务实取舍。1.3 两者最本质的区别磁盘与内存的较量MySQL 和 Redis 本质区别就一句话MySQL 是为数据安全设计的Redis 是为速度设计的。MySQL 把数据写进磁盘用 WALWrite-Ahead Logging机制保证宕机不丢数据Redis 默认只在内存里操作即使开启 AOF/RDB 持久化也存在秒级甚至分钟级的数据丢失窗口。两者在数据模型上也有本质差异。MySQL 是结构化查询通过 SQL 语言对二维表做各种 join、group by、子查询Redis 是键值操作每个 key 对应一个 value你没法对两个 key 做“连接查询”所有关联关系得自己在应用层维护。就好比 MySQL 是超市的仓库货物分门别类放在固定货架上任何货物都能通过统一的盘点系统查询Redis 是一个随身携带的小储物柜柜子里的东西拿取极快但柜子空间有限而且东西多了以后找起来得自己记着每个柜子放的是什么。2. 一张表看懂 MySQL 和 Redis 的区别2.1 核心指标全面对比对比维度MySQLRedis数据存储位置磁盘内存做 buffer pool 加速内存磁盘仅用于持久化备份数据模型二维表 SQL键值对 多种数据结构读写性能单机每秒数千到数万级单实例每秒十万级O(1) 操作数据持久性高崩溃可恢复最多丢最近一次 commit 的数据低默认可能丢数秒数据事务支持ACID 完整事务单命令原子 MULTI/EXEC 事务但不完全隔离扩展方式主从复制、读写分离、分库分表主从复制、Redis Cluster 分片典型数据量几百 GB 到数 TB 都正常受内存限制一般几十 GB 以内查询方式支持复杂关联查询、聚合、子查询只支持基于 key 的模式查询无 join适用场景系统核心数据、业务主存储缓存、计数器、排行榜、分布式锁2.2 从数据一致性角度理解差异MySQL 有完整的 ACID 事务保证最核心的是持久性Durability。一个事务只要成功 commit数据就不会因为进程崩溃而丢失这是通过 redo log 先持久化、数据页后落盘的方式实现的。Redis 呢它在默认配置下AOF 持久化是 everysec也就是说最多可能丢 1 秒的写操作。如果你把 appendfsync 改成 always性能会显著下降但数据安全性也只能接近 MySQL 的水平也不是绝对的。还有个更隐蔽的区别MySQL 天然支持强一致性读。在 RR 隔离级别下一个事务内多次查询看到的是同一快照在 RC 级别下每次查询看到的是最新已提交数据。Redis 没有这种“快照隔离”概念多个客户端同时读写同一个 key谁最后执行谁就覆盖前面的结果完全靠应用层自己处理。2.3 存储成本与容量规划的现实差异这一节是实际项目里最容易坑人的地方。MySQL 的存储成本按磁盘算1TB 的 SSD 买起来并没有那么心疼Redis 是按内存算的内存价格是磁盘的几十倍。同样存 1GB 数据MySQL 可能只占 1.5GB 空间表结构 索引Redis 因为本身是内存数据结构且需要额外指针、元信息占用可能到 2GB 甚至更多。所以你在项目里做容量规划的时候Redis 的估算公式要考虑三部分实际数据大小、数据结构本身的 overhead、以及 Redis 的内存碎片率。碎片率可以在 INFO memory 里看 mem_fragmentation_ratio如果长期大于 1.5说明碎片问题严重需要考虑重启或启用内存整理。这个命令我每季度都会看一眼很多时候内存报警不是因为数据多了而是因为碎片多了。3. 项目实战MySQL 和 Redis 到底怎么配合用3.1 项目中最经典的组合模式MySQL 为底Redis 加速在绝大多数中小型项目中最标准的组合套路是这样的MySQL 存全量核心数据Redis 缓存高频访问数据。当客户端请求到达时应用先去 Redis 里查查到了直接返回查不到再去 MySQL 里查查出来回填到 Redis 并设置过期时间。这套逻辑叫 cache aside pattern是目前最普及的缓存模式。代码实现大概是这样的思路public User getUserById(Long userId) { // 1. 先从 Redis 查 String cached redis.get(user: userId); if (cached ! null) { return JSON.parse(cached); } // 2. 缓存没有去 MySQL 查 User user userMapper.selectById(userId); if (user ! null) { // 3. 回填缓存过期时间 30 分钟 redis.set(user: userId, JSON.toJsonString(user), 1800); } return user; }这套代码看着简单实际操作中有三个细节需要注意。第一缓存穿透问题如果用户 id 根本不存在MySQL 返回 null缓存里什么都没有每次请求都会穿透到数据库。解决办法是缓存空值并设置较短的过期时间比如 5 分钟。第二缓存击穿问题某一个热点 key 恰好在那一瞬间过期大量请求同时打到 MySQL。解决办法是加互斥锁只让一个线程去 MySQL 回源其他线程等待。第三缓存雪崩问题如果大量 key 设置了同一个过期时间在某一个时刻同时失效数据库压力瞬间爆炸。解决办法是给过期时间加一个随机偏移量比如 1800 random(0, 300)。3.2 为什么不能用 Redis 替代 MySQL 存储核心业务数据有些初学者会想Redis 这么快直接把数据全放 Redis 不就行了如果你做一个 demo 或者纯内存排行榜那确实可以但凡是涉及订单、用户资产、交易流水这类核心数据这个想法就是灾难。最直接的例子电商系统里用户下单后要扣减库存这个操作必须在 MySQL 事务里完成还要配合行锁。因为库存是一个需要强一致性的数据不能出现“下单成功但库存扣多了/扣少了”的情况。Redis 的 DECR 命令虽然原子但它无法回滚如果后续流程失败比如支付超时你还需要在业务代码里 INCR 加回去这个过程一旦有并发条件竞争库存就乱了。另外Redis 的数据量受限于内存。如果业务量涨到一定程度核心数据完全放 Redis 的话你得买多少内存成本高得离谱。而且 Redis Cluster 虽然支持水平扩容但它以 slot 为单位做数据分片跨 slot 的多 key 操作比如 transaction就受限了。MySQL 通过分库分表也能扩容但那是另外一个维度的复杂工程。3.3 真实项目中的缓存更新策略延迟双删与最终一致缓存更新的坑比大多数人想象的要深。直接做“先更新数据库再删除缓存”其实并不是百分百安全的。来看这个并发场景A 线程更新了数据库然后删缓存但在删缓存之前网络延迟或者 GC 停顿B 线程来读缓存发现没删掉读到旧值返回了。或者A 线程更新数据库之后B 线程读到旧数据并回填缓存然后 A 线程才删缓存那缓存里就永远是旧数据了。业界常用的解决办法之一是延迟双删。逻辑是先更新数据库 - 删除缓存 - 等待一小段时间比如 500ms- 再次删除缓存。第二次删除的目的是清掉并发读请求在第一次删除之后回填的旧数据。延迟时间要比“读请求回填缓存所需的时间”长一点点。这个方法虽然不完美极端情况下还是会出问题但在绝大多数业务场景下已经够用了。另一个办法是引入消息队列做可靠缓存更新。Spring Boot Canal 监听 MySQL 的 binlog 变更然后把变更事件发到 MQ由消费者去更新 Redis。这个方案的好处是数据库变更和缓存更新彻底解耦而且可以在消费者端做幂等处理和重试。缺点是要额外引入 Canal 和 MQ 两套中间件中小项目用起来性价比不高。我的建议是核心数据且一致性要求高走 binlog 同步普通热点数据延迟双删就够了。4. 高频场景解剖排行榜、计数器、分布式锁和 Session4.1 排行榜业务Redis ZSet 是天然的榜单神器排行榜是 Redis 最经典的应用场景之一。ZSet 的每个成员关联一个 scoreRedis 底层用跳表实现按 score 排序所以获取 Top N 的时间复杂度是 O(logN M)性能极佳。实际项目中我们做一个游戏积分排行榜ZADD leaderboard 1000 user:1 录入或更新分数ZINCRBY leaderboard 50 user:1 给用户加分ZREVRANGE leaderboard 0 9 WITHSCORES 取 Top 10ZRANK leaderboard user:1 查自己的排名这里最容易被忽略的是相同分数时的排名问题。ZSet 的排名是按 score 升序或降序排列如果两个用户分数一样排名先后取决于成员字符串的字典序。如果业务上要求“先达到该分数的排在前面”那么光靠 ZSet 一个 score 是表达不了的。通常的工程方案是构造一个组合 score实际分数 × 1000000 (某个基准时间戳 - 达到时间)。这样就能实现在同分场景下先到达者排名靠前。4.2 计数器与限流INCR 的威力与陷阱Redis 的 INCR / DECR 是原子操作底层依赖单线程模型天然适合做计数器。典型场景是统计文章点击量、接口调用次数、用户每日签到等。但这里有个大坑高并发下多次 INCR 会产生大量 RDB 和 AOF 的磁盘写入。如果配置了每秒刷盘几百个 key 同时高频 INCR 会极大消耗 IO。实践中我会采用批量合并刷盘的策略把计数先累加在应用内存里每 5 秒批量 PIPELINE 提交一次同时接受 Redis 重启时最多损失这 5 秒的计数精度。对于点击量这类非关键业务完全可以接受。限流方面最经典的方案是滑动窗口 ZSet。每次请求来的时候ZADD 一个当前时间戳的成员然后 ZREMRANGEBYSCORE 删除窗口之前的记录再 ZCARD 统计当前窗口内的请求数。这个方案的优点是精确缺点是每个 key 都要维护一个 ZSet内存消耗大。更轻量的做法是用 INCR EXPIRE 做固定窗口限流虽然窗口边界会有毛刺但一般场景足够用了。4.3 分布式锁从 SETNX 到 Redisson 的进化之路分布式锁是 Redis 在微服务场景下最硬核的使用场景。最基础的版本是 SETNX key value拿到锁就执行执行完 DEL。但这里有两个经典坑持有锁的线程执行时间太长锁过期了另一个线程拿到锁了第一个线程执行完 DEL 把别人的锁删了。持有锁的线程宕机了锁永远不释放但设置过期时间可以缓解。正确的做法是锁的 value 存一个唯一标识比如 UUID删除锁的时候先 GET 再比较再 DEL。这个过程必须用 Lua 脚本保证原子性if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end如果要做锁的自动续期防止业务没执行完锁就过期自己实现非常麻烦。生产环境我强烈建议直接用 Redisson 框架它提供了看门狗机制默认每 10 秒续期一次锁的有效期默认 30 秒。但是要注意Redisson 的看门狗只对你自己创建的 lock 生效如果你用 Redisson 的 getLock 方法创建的锁它会自动续期如果用 tryLock 传了 leaseTime 参数它就不会自动续期了。4.4 Session 共享与 Token 缓存在分布式场景下用户的登录态必须多个服务节点共享。传统 Tomcat 的 Session 只是在单机上有效负载均衡一轮询用户就被迫重新登录了。业界两种方案一是 Spring Session Redis 把 Session 存在 Redis 里二是更主流的 JWT Token 本身无状态。但 JWT 有个问题是无法主动失效遇到封号、踢人下线的场景很尴尬。所以现在很多系统的做法是JWT 负责无状态鉴权Redis 里存一个 token 黑名单被踢掉的 token 在有效期内临时拉黑。这样既规避了 JWT 不可撤销的问题又不需要在每个请求里都查数据库。5. 环境搭建与配置要点不走弯路的操作实录5.1 MySQL 8.0 安装与配置的保姆级步骤安装 MySQL 其实很多人在这里栽过跟头。Linux 环境下推荐直接用官方 yum 仓库或者 apt 仓库不要用编译安装浪费时间。以 CentOS 为例# 添加官方仓库 wget https://dev.mysql.com/get/mysql80-community-release-el7-3.noarch.rpm rpm -Uvh mysql80-community-release-el7-3.noarch.rpm # 安装 yum install mysql-community-server -y # 启动 systemctl start mysqld # 查看初始密码 grep temporary password /var/log/mysqld.log初始密码是随机生成的第一次登录后必须马上改密码。这里有个容易踩的坑MySQL 8.0 默认的密码校验级别很高初始密码里强制要求大小写字母、数字和特殊符号的组合如果只想用简单密码得先降低 validate_password 策略SET GLOBAL validate_password.policy LOW; SET GLOBAL validate_password.length 6; ALTER USER rootlocalhost IDENTIFIED BY 123456;如果你用的是 Windows 免安装版zip 方式关键不仅仅是 my.ini 的配置还要注意bin 目录必须加进系统 PATH且 data 目录需要在第一次安装时初始化。命令行执行mysqld --initialize-insecure生成 data 目录否则启动会报找不到 data 目录的错误。很多人卡在这一步其实原因是没初始化。5.2 Redis 安装与 Docker 主从搭建实战Redis 的安装比 MySQL 简单得多Linux 下直接yum install redis或者源码编译都可以。这里更推荐用 Docker 方式部署 Redis 主从管理和迁移都方便。# 拉取镜像 docker pull redis:7.0 # 启动主节点 docker run -d --name redis-master \ -p 6379:6379 \ -v /data/redis-master:/data \ redis:7.0 redis-server --appendonly yes # 启动从节点 docker run -d --name redis-slave \ -p 6380:6379 \ -v /data/redis-slave:/data \ redis:7.0 redis-server --appendonly yes \ --slaveof 192.168.1.100 6379从节点启动命令里的 --slaveof 就是指定主节点地址。配置完成之后用redis-cli -p 6380 info replication查看角色如果显示role:slave并且master_link_status:up说明主从复制正常。测试方法在主节点 set 一个 key在从节点 get如果能查到就说明同步成功。如果要在同一个 Docker 网络里跑多个 Redis 做一主一从一哨兵核心是注意容器间的 hostname 不能写 127.0.0.1要写服务名或者真实容器 IP。这个坑我遇到过好几次刚搭好的主从复制看着配好了日志里一直报连接超时查了大半天发现是配置里写错了 IP。5.3 可视化客户端与日常运维命令开发调试时没有趁手的 GUI 工具效率太低。MySQL 我推荐 MySQL Workbench 或者 DBeaverRedis 推荐 Redis Desktop ManagerRDM或者 Another Redis Desktop Manager。RDM 早期版本不支持 Redis 6/7 的 ACL 认证连接会报错需要升级到新版。日常运维命令有几个高频且容易混淆的# Redis 查看所有 key redis-cli keys * # 生产环境谨慎使用 keys会阻塞单线程可以用 scan 代替 redis-cli scan 0 match user:* count 100 # 查看内存 redis-cli info memory # 查看慢日志 redis-cli slowlog get 10 # MySQL 查看慢查询 SHOW VARIABLES LIKE slow_query_log%; SELECT * FROM mysql.slow_log ORDER BY start_time DESC LIMIT 10;6. 典型故障案例与排查思路全是实操经验6.1 缓存穿透导致的数据库雪崩我之前维护的一个查询商品详情的接口某天监控突然报警数据库 QPS 飙升到平时的 5 倍。排查发现有人恶意用大量不存在的商品 ID 循环请求Redis 里查不到每次都穿透到 MySQL数据库差点被打挂。解决办法分两步第一步立即在代码中加缓存空值策略把 -1 之类的占位值缓存 5 分钟第二步配合布隆过滤器但项目里没有现成的最终用了更简单的方案参数校验层拦截明显不存在的负数和超大值再用空值缓存兜底。上线后数据库 QPS 立刻恢复正常。6.2 Redis 内存突然暴涨又断崖下跌有一次 Redis 实例内存使用率到 80% 后突然断崖下跌监控图上像被砍了一刀。排查发现是大量设置了同一时间过期时间的 key 集中过期导致内存瞬间释放。表面看是内存问题本质上是使用方设计不当一个大列表的缓存 key 都设置了相同的 1 小时过期时间。优化方案是过期时间加随机偏差并且在批量写缓存时用 PIPELINE 减少 RTT。6.3 MySQL 和 Redis 数据不一致的一次真实事故某个订单状态模块我们用了“先更新 MySQL 再删除缓存”的策略结果出现用户查询订单状态比实际慢了两分钟的情况。当时分析原因更新 MySQL 成功 - 删除 Redis 缓存 - 但在删除时 Redis 网络抖动失败代码里删除异常被吞了- 缓存一直是旧值。那次之后我彻底改成延迟双删并且删除缓存失败时记录日志并进入重试队列。还有一个教训是任何删除 Redis 的操作都要打日志否则出了问题你完全不知道是哪一步失败了。6.4 MySQL 慢查询的定位三板斧MySQL 出现慢查询时我的排查步骤基本是固定的。第一步开启慢查询日志设置 long_query_time 1 秒第二步用 EXPLAIN 分析核心 SQL重点看 type 字段all全表扫描和 index全索引扫描是关键嫌疑第三步确认是否命中了索引比如 key 字段是否为 null 或者 potential。最常见的坑是函数包裹导致索引失效比如 WHERE DATE(create_time) 2024-01-01 用不上索引应该改为 create_time 2024-01-01 AND create_time 2024-01-02。判断是否需要深度优化主要看 rows 扫描行数是否远超实际返回行数。7. 面试高频考点从原理到项目的回答框架7.1 你项目里 Redis 缓存和 MySQL 是怎么配合的面试官问这个问题的核心是考察你是否有真实项目经验而不是背八股。推荐用 STAR 法则回答背景Situation是某个接口并发量高、数据库压力大任务Task是通过缓存降低数据库读压力行动Action是采用 cache aside pattern先读 Redis 不中再查 MySQL回填时设置随机过期时间配合空值缓存防止穿透结果Result是数据库 QPS 下降 60%接口响应时间从 200ms 降到 20ms。这比干背“缓存穿透、击穿、雪崩”三个名词要有说服力得多。7.2 MySQL 索引为什么用 B 树这个问题的标准答法是B 树是多路搜索树高度固定且很低三层可以存储千万级数据叶子节点用双向链表串联天然支持范围查询所有数据都存在叶子节点非叶子节点只存索引键所以单次磁盘 IO 能读入更多键。对比哈希索引哈希只能做等值查询做不了范围查询对比红黑树红黑树|的高度随数据量线性增长数据量大时 IO 次数不可接受。回答的时候能画出示意图说明三层 B 树怎么存储两千万条数据就非常加分。7.3 Redis 为什么快答案分四层第一层内存操作数据读写不触碰磁盘纳秒级内存访问周期对比毫秒级磁盘寻道周期是数量级差距第二层单线程模型避免了线程上下文切换和锁竞争同时基于 epoll 的多路复用 IO 在单线程内处理海量连接第三层高效的数据结构设计比如 SDS、跳表、quicklist都是为了减少时间和空间开销第四层IO 多路复用技术本身Redis 事件处理器基于 Reactor 模式收到网络请求后交给事件分发器处理整个过程是事件驱动而不是阻塞等待。7.4 缓存和数据库的一致性怎么保证这是一个开放性问题面试官看重你的思路。核心点是强一致性不可能做到只能追求最终一致性。方案排序是这样递进的第一级更新数据库之后删除缓存配合失败重试和日志追踪第二级延迟双删缓解并发读数量大时回填旧数据的窗口第三级引入 Canal 监听 binlog异步更新缓存保证数据库成功提交后缓存最终更新第四级如果是资金类数据如余额干脆不要缓存直接查 MySQL用 Redis 做分布式锁防止并发修改。能把这个递进过程讲清楚说明你真的理解了系统设计的取舍。8. 学习路径与个人经验先说一下我理解的脉络。如果你刚接触这两个东西不要上来就啃源码而是先搭起来、跑起来然后用断点或者 Redis-CLI 观察行为最后再深入到原理。MySQL 的学习顺序是SQL 基础 - 索引 - 事务隔离级别 - 锁 - 优化器 - 主从复制 - 分库分表。Redis 的学习顺序是五种基础数据结构 - 持久化 - 过期策略与内存淘汰 - 分布式锁 - 集群方案。我个人在实际项目中体会到最深的一件事是中间件的选择永远服务于业务场景不是越新越好。MySQL 很“钝”但它可靠Redis 很“快”但它需要你小心翼翼地去维护它的数据边界。一套靠谱的缓存方案不只是 Redis 里 set 一个 key 那么简单它涉及过期策略、一致性、代码里的失败重试、监控报警、容量规划这么多维度。最后再分享一个小技巧没有完美的架构选型但可以在推进每一个项目时多追问一句“如果这里 Redis 挂了我的系统会怎样”。如果你能把这句话变成潜意识里的习惯而不是停留在背概念、背面试题的阶段那这篇文章就真正起到了它该起的作用了。