可重复读解决了哪些问题？
可重复读的核心就是一致性读(consistent read);保证多次读取同一个数据时，其值都和事
务开始时候的内容是一致，禁止读取到别的事务未提交的数据，会造成幻读。
而事务更新数据的时候，只能用当前读。如果当前的记录的行锁被其他事务占用的话，就
需要进入锁等待。
查询只承认在事务启动前就已经提交完成的数据。
可重复读解决的是重复读的问题，可重复读在快照读的情况下是不会有幻读，但当前读的
时候会有幻读。
对 SQL 慢查询会考虑哪些优化 ？
分析语句，是否加载了不必要的字段/数据。
分析 SQL 执行计划（
explain extended），思考可能的优化点，是否命中索引等。
查看 SQL 涉及的表结构和索引信息。 如果 SQL 很复杂，优化 SQL 结构。
按照可能的优化点执行表结构变更、增加索引、SQL 改写等操作。
查看优化后的执行时间和执行计划。
如果表数据量太大，考虑分表。
利用缓存，减少查询次数。
谈一谈缓存穿透、缓存击穿和缓存雪崩，以及解决办法？
缓存穿透
问题：大量并发查询不存在的 KEY，在缓存和数据库中都不存在，同时给缓存和数据库
带来压力。
原因：一般而言，缓存穿透有 2 种可能性：业务数据被误删，导致缓存和数据库中都没
有数据。恶意进行 ddos 攻击。
分析：为什么会多次透传呢？不存在 一直为空，需要注意让缓存能够区分 KEY 不存在和
查询到一个空值。
解决办法：缓存空值的 KEY，这样第一次不存在也会被加载会记录，下次拿到有这个
KEY。Bloom 过滤或 RoaingBitmap 判断 KEY 是否存在，如果布隆过滤器中没有查到
这个数据，就不去数据库中查。在处理请求前增加恶意请求检查，如果检测到是恶意攻击，
则拒绝进行服务。完全以缓存为准，使用延迟异步加载的策略（异步线程负责维护缓存的
数据，定期或根据条件触发更新），这样就不会触发更新。
缓存击穿
问题：某个 KEY 失效的时候，正好有大量并发请求访问这个 KEY。
分析：跟穿透其实很像，属于比较偶然的。
解决办法：KEY 的更新操作添加全局互斥锁。完全以缓存为准，使用延迟异步加载的策
略（异步线程负责维护缓存的数据，定期或根据条件触发更新），这样就不会触发更新。
缓存雪崩
问题：当某一时刻发生大规模的缓存失效的情况，导致大量的请求无法获取数据，从而将
流量压力传导到数据库上，导致数据库压力过大甚至宕机。
原因：一般而言，缓存雪崩有 2 种可能性：大量的数据同一个时间失效：比如业务关系
强相关的数据要求同时失效 Redis 宕机
分析：一般来说，由于更新策略、或者数据热点、缓存服务宕机等原因，可能会导致缓存
数据同一个时间点大规模不可用，或者都更新。所以，需要我们的更新策略要在时间上合
适，数据要均匀分享，缓存服务器要多台高可用。
解决办法：更新策略在时间上做到比较平均。如果数据需要同一时间失效，可以给这批数
据加上一些随机值，使得这批数据不要在同一个时间过期，降低数据库的压力。使用的热
数据尽量分散到不同的机器上。多台机器做主从复制或者多副本，实现高可用。做好主从
的部署，当主节点挂掉后，能快速的使用从结点顶上。实现熔断限流机制，对系统进行负
载能力控制。对于非核心功能的业务，拒绝其请求，只允许核心功能业务访问数据库获取
数据。服务降价：提供默认返回值，或简单的提示信息。
学习之路贵在坚持，关注我！
浩说编程陪你每天三道高频面试题，日积月累一定会有所收获！
