https://hangliuc.github.io/tags/database/Recent content in Database on HRunningHugo -- gohugo.iozh-cnHRunningWed, 09 Sep 2026 15:51:15 +0800https://hangliuc.github.io/topic/interview/database/Sat, 06 Dec 2025 18:42:12 +0800https://hangliuc.github.io/topic/interview/database/<img src="https://hangliuc.github.io/img/cover/interview_cover.webp" alt="Featured image of post SRE面试题汇总 | Database" /><h1 id="mysql">mysql </h1><h2 id="mysql-查询突然变得很慢需要怎么排查">mysql 查询突然变得很慢，需要怎么排查 </h2><h3 id="检查查询本身">检查查询本身 </h3><ul> <li>查看SQL查询是否可以优化，比如使用合适的索引、避免全表扫描等。</li> <li>复杂的JOIN操作：确认是否有多个大的表连接，或者是不必要的复杂操作</li> </ul> <h3 id="查看数据库性能">查看数据库性能 </h3><p>慢查询日志：启用并查看慢查询日志（slow_query_log）。查看最近哪些查询执行时间较长。</p> <h3 id="检查系统负载">检查系统负载 </h3><p>系统资源：查看CPU、内存、磁盘IO、网络等资源是否有瓶颈，可以通过 top 或 htop 等工具监控。 磁盘IO：查看磁盘读写是否成为瓶颈。可以用 iostat 或 vmstat 等工具查看磁盘IO情况。</p> <h3 id="检查锁和并发问题">检查锁和并发问题 </h3><p>锁情况：查看是否有锁等待或死锁问题。使用以下SQL语句查看当前的锁状态： 如果有很多线程处于“Locked”状态，可能需要进一步分析锁的来源和解决方法。</p> <h3 id="网络延迟">网络延迟 </h3><p>如果是远程连接MySQL，确认网络连接是否稳定，延迟是否较高。</p> <h1 id="redis">redis </h1><h2 id="热-key大-key-问题">热 Key、大 Key 问题 </h2><h3 id="热key问题">热key问题 </h3><ul> <li>热key：指被频繁访问的key，可能导致数据库性能下降。</li> </ul> <p>影响：</p> <ul> <li>CPU 集中在一个 Redis 节点</li> <li>QPS 不均匀，集群负载失衡</li> <li>延迟飙升、请求超时</li> <li>导致节点触发 failover</li> </ul> <p>解决方案</p> <ul> <li>业务层分流/分桶 将热请求拆成多个 key，提高并发承载。</li> <li>增加缓存层：本地缓存 + Redis 二级缓存，减少对 Redis 的直接访问</li> <li>使用多 Key 拆分读压力，一个热门大 key 分成多个子 key</li> <li>Redis Proxy 层热点保护，代理层可识别热点并做降级</li> <li>客户端本地限流 + 降级</li> </ul> <h3 id="大key问题">大key问题 </h3><ul> <li>大key：指key对应的值非常大，占用了大量的内存空间。</li> </ul> <p>影响：</p> <ul> <li>迁移槽时（CLUSTER ADDSLOTS/MIGRATE）非常慢</li> <li>可能阻塞 Redis 主线程</li> <li>删除时触发阻塞（del O(n) 操作</li> <li>压垮网络带宽</li> <li>读写延迟变大</li> <li>Failover 恢复慢</li> </ul> <p>解决方案</p> <ul> <li>业务层拆分：将大 key 拆分成多个小 key，每个小 key 只存储一部分数据。</li> <li>分页读取：不使用 hgetall/smembers/zrange，使用scan / 分段取</li> <li>提前限制 value 的大小： 在服务侧做 key 大小限制</li> <li>避免在 Redis 存储日志、消息、长文本</li> </ul> <p>如何发现大key</p> <ul> <li>Redis的SCAN命令</li> <li>redis-cli -h 127.0.0.1 -p 6379 —bigkeys</li> <li>开源工具Redis RDB Tools，分析RDB文件，扫描出Redis大key。</li> </ul> <h1 id="kafka">kafka </h1><h2 id="消费堆积如何处理">消费堆积如何处理 </h2><h3 id="消息堆积原因">消息堆积原因 </h3><ul> <li>生产者短时间内生产大量消息到Topic，消费者无法及时消费。</li> <li>消费者的消费能力不足（消费者并发低、消息处理时间长），导致消费效率低于生产效率。</li> <li>消费者异常（如消费者故障、消费者网络异常等）导致无法消费消息。</li> <li>Topic分区设置不合理，或新增分区无消费者消费。</li> <li>Topic频繁重分配导致消费效率降低。</li> </ul> <h3 id="解决方法">解决方法 </h3><p>从消息堆积的原因看，消息堆积问题可以从消费者端、生产者端和服务端三个方面进行处理。</p> <ul> <li>消费者端 <ul> <li>根据实际业务需求，合理增加消费者个数（消费并发度），确保分区数/消费者数=整数，建议消费者数和分区数保持一致。</li> <li>提高消费者的消费速度，通过优化消费者处理逻辑（减少复杂计算、第三方接口调用和读库操作），减少消费时间。</li> <li>增加消费者每次拉取消息的数量：拉取数据/处理时间 &gt;= 生产速度。</li> </ul> </li> <li>生产者端 <ul> <li>生产消息时，给消息Key加随机后缀，使消息均衡分布到不同分区上。</li> </ul> </li> <li>服务端 <ul> <li>合理设置Topic的分区数，在不影响业务处理效率的情况下，调大Topic的分区数量。</li> <li>当服务端出现消息堆积时，对生产者进行熔断，或将生产者的消息转发到其他Topic。</li> </ul> </li> </ul>