电话面试数据库总结

这次分享的是有关数据库的面试问题。

1.什么是悲观锁

悲观锁的特点是先获取锁，再进行业务操作，即“悲观”的认为获取锁是非常有可能失败的，因此要先确保获取锁成功再进行业务操作。通常所说的“一锁二查三更新”即指的是使用悲观锁。通常来讲在数据库上的悲观锁需要数据库本身提供支持，即通过常用的select … for update操作来实现悲观锁。当数据库执行select for update时会获取被select中的数据行的行锁，因此其他并发执行的select for update如果试图选中同一行则会发生排斥（需要等待行锁被释放），因此达到锁的效果。select for update获取的行锁会在当前事务结束时自动释放，因此必须在事务中使用。

这里需要注意的一点是不同的数据库对select for update的实现和支持都是有所区别的，例如oracle支持select for update no wait，表示如果拿不到锁立刻报错，而不是等待，mysql就没有no wait这个选项。另外mysql还有个问题是select for update语句执行中所有扫描过的行都会被锁上，这一点很容易造成问题。因此如果在mysql中用悲观锁务必要确定走了索引，而不是全表扫描。

2.什么是乐观锁

乐观锁的特点先进行业务操作，不到万不得已不去拿锁。即“乐观”的认为拿锁多半是会成功的，因此在进行完业务操作需要实际更新数据的最后一步再去拿一下锁就好。

乐观锁在数据库上的实现完全是逻辑的，不需要数据库提供特殊的支持。一般的做法是在需要锁的数据上增加一个版本号，或者时间戳

乐观锁是否在事务中其实都是无所谓的，其底层机制是这样：在数据库内部update同一行的时候是不允许并发的，即数据库每次执行一条update语句时会获取被update行的写锁，直到这一行被成功更新后才释放。因此在业务操作进行前获取需要锁的数据的当前版本号，然后实际更新数据时再次对比版本号确认与之前获取的相同，并更新版本号，即可确认这之间没有发生并发的修改。如果更新失败即可认为老版本的数据已经被并发修改掉而不存在了，此时认为获取锁失败，需要回滚整个业务操作并可根据需要重试整个过程。

3.悲观锁和乐观锁的使用场景

乐观锁在不发生取锁失败的情况下开销比悲观锁小，但是一旦发生失败回滚开销则比较大，因此适合用在取锁失败概率比较小的场景，可以提升系统并发性能

悲观锁还适用于一些比较特殊的场景，例如在业务操作过程中无法和数据库保持连接等悲观锁无法适用的地方

4.Mysql数据库隔离级别

数据库事务特性 事务具有 4 个特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持续性（Durability）。这 4 个特性简称为 ACID 特性。

在实际的运用情况下实现ACID是非常困难的，而且性能上也会大打折扣，很多时候不同的业务对事务的要求不一样，所以为了提升性能并满足业务，数据库提供了4种不同的隔离级别来供用户选择

未提交读（Read UNCOMMITTED）: 这种级别，当一个事务对数据进行修改后，即使没有提交，也会被其他事务读取到，高并发状态下极易产生脏读。

已提交读（READ COMMITTED）：在一个事务的整个操作过程中，所有的数据修改对其他事务不可见，但这种情况下会导致其他事务中产生不可重复读（即两次读取结果不一致），这个级别也叫作不可重复读

可重复读（REPEATABLE READ）：Mysql的默认事务隔离级别，该级别可以保证一个事务在整个流程中，多次读取同样记录的结果相同，但是没有解决幻读的问题。

可串行化（SERIALIZABLE）：是事务最高隔离级别，对同一张表的所有的读写都会阻塞，每次都需要获取表级共享锁

数据库的事务隔离越严格,并发副作用越小,但付出的代价也就越大,因为事务隔离实质上就是使事务在一定程度上“串行化”进行,这显然与“并发”是矛盾的。

同时,不同的应用对读一致性和事务隔离程度的要求也是不同的,比如许多应用对“不可重复读"和“幻读”并不敏感,可能更关心数据并发访问的能力。

5.mysql索引底层哪种数据结构的

B+Tree的搜索与B-Tree也基本相同，区别是B+Tree只有达到叶子结点才命中（B-Tree可以在非叶子结点命中），其性能也等价于在关键字全集做一次二分查找；

6.mysql 为什么不用B tree

所有关键字都出现在叶子结点的链表中（稠密索引），且链表中的关键字恰好是有序的；不可能在非叶子结点命中；非叶子结点相当于是叶子结点的索引（稀疏索引），叶子结点相当于是存储（关键字）数据的数据层；更适合文件索引系统

B-Tree 特性

关键字集合分布在整颗树中；任何一个关键字出现且只出现在一个结点中；

搜索有可能在非叶子结点结束；其搜索性能等价于在关键字全集内做一次二分查找；自动层次控制

7.redis 存储机制

RDB持久化:就是对redis中的数据执行周期性的数据快照备份，这个周期可以自己配置。

AOF持久化:机制对每条写入命令都以append-only的模式写入一个日志文件中，在redis重启的时候，可以通过回放AOF日志中的写入指令来重新构建整个数据集，append-only可以配置异步或同步。