正文

MySQL高并发下数据库崩溃怎么办缓存击穿如何解决慢查询优化实战案例

/0 浏览量
0715

想象一下，凌晨两点，你正端着咖啡准备享受难得的宁静，突然手机疯狂震动。监控大屏上的 QPS（每秒查询率）曲线像过山车一样直冲云霄，紧接着，数据库连接数瞬间爆满，应用服务器开始大面积报错 Too many connections，用户端全是白屏或超时。那一刻，心跳漏了一拍——这是典型的“高并发压垮数据库”现场。

别慌，作为在这个行业摸爬滚打多年的老兵，我见过太多类似的“至暗时刻”。这不仅仅是技术故障，更是一场关于架构设计、缓存策略和SQL优化的综合大考。今天，我们不讲枯燥的理论，而是直接切入这三个最让人头秃的核心痛点：防崩盘、防击穿、防慢查，并给出能落地的实战方案。

一、 当洪水来袭：MySQL高并发下的“保命”指南

首先，我们要纠正一个常见的误区：数据库不是用来扛高并发的，它是用来存数据的。 试图让 MySQL 直接承受百万级 QPS，就像让一辆拖拉机去跑F1赛车，迟早会散架。

1. 第一道防线：应用层限流与降级

当流量洪峰到来时，最先倒下的往往是数据库连接池。在请求到达数据库之前，必须在应用层（如 Spring Boot + Sentinel/Resilience4j）进行拦截。

  • 令牌桶算法：限制每秒处理的请求数量。超过阈值的请求直接返回友好提示或排队等待，而不是强行涌入数据库。
  • 服务降级：对于非核心业务（如评论数、点赞数），在高并发期间可以暂时关闭实时计算，改为异步处理或返回默认值，确保核心交易链路畅通。

2. 第二道防线：缓存前置，分担压力

绝大多数读请求都应该由 Redis 或 Memcached 承担。只有当缓存未命中或需要强一致性数据时，才穿透到数据库。

  • 热点数据预热：在活动开始前，将可能成为热点的商品、文章加载到缓存中，避免流量高峰时的冷启动冲击。
  • 本地缓存 + 分布式缓存：对于极热点数据（如首页配置），可以在 JVM 内存中设置一级本地缓存（如 Caffeine），再配合 Redis 二级缓存，大幅减少网络IO和数据库压力。

3. 第三道防线：数据库自身的“硬抗”技巧

如果必须直面数据库，我们需要从配置和架构上做极致优化：

  • 调整连接池参数：检查 HikariCP 或 Druid 的配置。maximumPoolSize 不宜过大，通常 CPU 核数 * 2 + 磁盘数 是一个经验值。过大的连接数会导致上下文切换开销剧增。
  • 读写分离：主库负责写，多个从库负责读。通过中间件（如 ShardingSphere）自动路由读请求，分散负载。
  • 垂直分库与水平分表：
    • 垂直分库：将用户库、订单库、商品库拆分到不同的物理实例上，避免单实例资源争抢。
    • 水平分表：当单表数据量超过千万级，查询性能会显著下降。使用哈希取模或范围分区，将数据分散到多个表中，降低单表锁竞争和索引大小。

实战案例：某电商平台大促期间，QPS 飙升至 5万+。初期直接全量查库，导致 CPU 满载，响应时间从 50ms 飙升至 2s 以上。后来引入 Sentinel 限流，将非核心接口（如用户积分查询）降级为返回缓存旧数据，同时开启 Redis 缓存预热。最终，数据库 CPU 稳定在 60% 左右，系统安然度过峰值。

二、 缓存的“阿喀琉斯之踵”：彻底解决缓存击穿

缓存击穿（Cache Breakdown）是指某个热点 Key 在缓存过期的一瞬间，大量并发请求同时打到数据库。这与缓存雪崩（大量 Key 同时过期）不同，击穿只针对单个热点 Key，但破坏力极大，因为所有流量都集中在这一条路径上。

场景还原

假设“iPhone 15 Pro Max”是全网爆款商品 ID 为 1001。

  1. 该商品缓存设置 TTL 为 1 小时。
  2. 第 3600 秒时，缓存过期。
  3. 此时，正好有一波秒杀流量涌入，请求 getItem(1001)。
  4. 由于缓存失效，这些请求全部穿透到 MySQL。
  5. MySQL 瞬间被拖垮。

解决方案对比

方案 原理 优点 缺点 适用场景
互斥锁（Mutex Lock） 只有一个线程去查库重建缓存，其他线程等待 保证数据一致性，实现简单 高并发下线程阻塞，性能有损耗 数据一致性要求高，并发适中
逻辑过期（Logical Expiry） 不设 TTL，获取缓存时判断是否过期，后台异步更新 无锁，性能极高 存在短暂的数据不一致 对实时性要求不高，高并发场景
永不过期 + 动态刷新 缓存 Key 永远不过期，通过后台任务定期刷新 最简单粗暴 无法做到实时性，内存占用需管理 静态配置类数据

实战代码：互斥锁方案（Redisson）

在 Java 生态中，推荐使用 Redisson 来实现分布式锁，因为它比原生 SETNX 更安全（支持看门狗机制，防止死锁）。

import org.redisson.api.RLock;
import org.redisson.api.RedissonClient;
import org.springframework.stereotype.Service;

import java.util.concurrent.TimeUnit;

@Service
public class ProductService {

    private final RedissonClient redissonClient;
    private final JdbcTemplate jdbcTemplate; // 假设用于查库

    public ProductService(RedissonClient redissonClient, JdbcTemplate jdbcTemplate) {
        this.redissonClient = redissonClient;
        this.jdbcTemplate = jdbcTemplate;
    }

    /**
     * 获取商品信息，带缓存击穿防护
     */
    public String getItemInfo(Long itemId) {
        String cacheKey = "item:" + itemId;
        
        // 1. 先从缓存获取
        String cachedValue = (String) redissonClient.getBucket(cacheKey).get();
        if (cachedValue != null) {
            return cachedValue;
        }

        // 2. 缓存为空，尝试获取分布式锁
        RLock lock = redissonClient.getLock("lock:" + cacheKey);
        try {
            // 尝试加锁，等待时间10秒，锁持有时间30秒（自动续期）
            if (lock.tryLock(10, 30, TimeUnit.SECONDS)) {
                try {
                    // 双重检查：防止在等待锁的过程中，其他线程已经重建了缓存
                    cachedValue = (String) redissonClient.getBucket(cacheKey).get();
                    if (cachedValue != null) {
                        return cachedValue;
                    }

                    // 3. 查数据库
                    System.out.println("Cache miss, querying DB for item: " + itemId);
                    String dbValue = queryFromDB(itemId);
                    
                    // 4. 写入缓存，设置合理TTL（例如1小时）
                    redissonClient.getBucket(cacheKey).set(dbValue, 1, TimeUnit.HOURS);
                    
                    return dbValue;
                } finally {
                    // 释放锁
                    lock.unlock();
                }
            } else {
                // 5. 获取锁失败，休眠后重试（退避策略）
                Thread.sleep(50); 
                return getItemInfo(itemId); // 递归重试
            }
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            throw new RuntimeException("Interrupted while waiting for lock", e);
        } catch (Exception e) {
            throw new RuntimeException("Error acquiring lock", e);
        }
    }

    private String queryFromDB(Long itemId) {
        // 模拟数据库查询
        return "Item Data for ID: " + itemId;
    }
}

关键点解析：

  1. 双重检查（Double-Check）：拿到锁后，再次检查缓存是否为空。因为在你等待锁的过程中，其他线程可能已经完成了重建。
  2. 重试机制：获取锁失败时，不要立即返回错误，而是短暂休眠后重试，这样用户体验更好。
  3. 看门狗：Redisson 默认开启看门狗，如果业务逻辑执行时间长于锁过期时间，会自动续期，避免业务没跑完锁就没了。

三、 抽丝剥茧：慢查询优化实战案例

慢查询是数据库性能的隐形杀手。它不会立刻让系统崩溃，但会长期占用连接资源，导致吞吐量下降。优化慢查询，核心在于理解执行计划和索引原理。

1. 发现慢查询

不要凭感觉优化，要用数据说话。

  • 开启慢查询日志：在 my.cnf 中配置 slow_query_log = ON 和 long_query_time = 1（超过1秒的记录）。
  • 使用工具分析：mysqldumpslow 或 Percona 的 pt-query-digest。

2. 经典案例：一张“大”表的优化之旅

背景： 某电商系统的 order_record 表，记录了过去3年的历史订单数据，数据量达到 5000 万行。 问题 SQL：

SELECT * FROM order_record 
WHERE user_id = 12345 
AND status = 1 
ORDER BY create_time DESC 
LIMIT 10;

现象：每次查询耗时 2-3 秒，CPU 利用率飙升。

第一步：查看执行计划

EXPLAIN SELECT * FROM order_record 
WHERE user_id = 12345 
AND status = 1 
ORDER BY create_time DESC 
LIMIT 10;

输出结果分析：

  • type: ALL （全表扫描！这是大忌）
  • key: NULL （没有用到索引）
  • rows: 50,000,000 （扫描了5000万行）
  • Extra: Using filesort （需要额外排序，IO 开销巨大）

原因诊断： 虽然 user_id 上有索引，但因为还过滤了 status，且涉及 ORDER BY，优化器认为全表扫描+排序比回表查询更快（或者根本没有合适的复合索引）。

第二步：索引优化

我们需要一个覆盖 user_id, status, create_time 的联合索引。根据最左前缀原则和排序需求，索引顺序至关重要。

  • 等值查询字段在前：user_id 和 status 是等值条件。
  • 范围/排序字段在后：create_time 用于排序。

创建索引：

ALTER TABLE order_record ADD INDEX idx_user_status_time (user_id, status, create_time);

再次 EXPLAIN：

  • type: ref （通过索引查找）
  • key: idx_user_status_time
  • rows: 1000 （假设每个用户平均1000条订单，远小于5000万）
  • Extra: Using index condition （使用了索引下推，效率提升）

此时，查询速度可能提升到 100ms 以内。但如果数据量继续增长，或者 status 区分度不高，可能还不够。

第三步：深分页与覆盖索引优化

如果业务需要翻页，比如 LIMIT 1000000, 10，即使有索引，MySQL 也需要回表查询 1000010 次，然后丢弃前 1000000 条，效率极低。

优化方案 A：覆盖索引（Covering Index） 如果 SELECT 的字段都在索引中，可以直接从索引树获取数据，无需回表。

-- 假设只需要查询 id 和 create_time
ALTER TABLE order_record ADD INDEX idx_user_status_time_id (user_id, status, create_time, id);

SELECT id, create_time FROM order_record 
WHERE user_id = 12345 AND status = 1 
ORDER BY create_time DESC LIMIT 10;

优化方案 B：延迟关联（Deferred Join） 先通过索引查出主键 ID，再关联原表获取其他字段。

SELECT o.* 
FROM order_record o
INNER JOIN (
    SELECT id FROM order_record 
    WHERE user_id = 12345 AND status = 1 
    ORDER BY create_time DESC 
    LIMIT 1000000, 10
) AS tmp ON o.id = tmp.id;

这样，子查询只需要走索引，返回少量 ID，外层关联再通过主键聚簇索引快速获取数据，避免了大量的随机 IO。

第四步：业务架构层面的终极解法

对于历史数据，冷热分离是王道。

  • 热数据：最近3个月的订单，存放在 MySQL 主表中，保证高性能。
  • 冷数据：3个月前的订单，归档到 Elasticsearch 或 HBase 中。
  • 查询路由：应用层根据时间范围，决定查 MySQL 还是查 ES。ES 天生适合海量数据的检索和聚合，且支持深度分页。

给小朋友也能听懂的比喻

  • 数据库就像一本巨大的图书馆目录书。
  • 全表扫描就是你不看目录，从第一页翻到最后一页找书，累死人。
  • 索引就是书的索引页，告诉你“张三的书在第50页”，直接翻过去。
  • 慢查询优化就是学会看索引页，并且把常用的书放在书架最顺手的位置。
  • 冷热分离就是把常看的书放桌面，不常看的书放地下室仓库。

四、 总结与心态建设

面对高并发、缓存击穿和慢查询，没有银弹，只有组合拳。

  1. 高并发靠的是分层防御：应用限流 -> 缓存削峰 -> 数据库读写分离/分库分表。
  2. 缓存击穿靠的是锁与重试：互斥锁保证一致性，异步构建保证可用性。
  3. 慢查询靠的是索引与架构：善用联合索引，避免深分页，长远看要做数据归档。

最后，我想说，技术故障不可怕，可怕的是缺乏预案。建立完善的监控告警体系（Prometheus + Grafana + Alertmanager），定期进行压测演练，才是工程师最好的“护身符”。

希望这篇实战指南能帮你在下一次流量洪峰中，从容地端起咖啡，微笑着看着监控大屏，说一句：“稳了。”

-- 展开阅读全文 --