数据库（面试向）

巴啦啦小刺猬

已于 2022-06-20 17:21:14 修改

阅读量914

点赞数

分类专栏： # 数据库文章标签：数据库 database

于 2022-06-11 16:47:39 首次发布

本文链接：https://blog.csdn.net/Olivia_BETTER/article/details/125216946

版权

本文深入探讨了数据库在面试中的重点内容，包括四大特性（原子性、一致性、隔离性、持久性）及其对并发控制的影响，详细解释了四种隔离级别，分析了悲观锁与乐观锁的适用场景。此外，文章还阐述了查询语句的执行顺序，以及视图、临时表和子查询的用途。主从复制的原理、策略和优势也被提及，对比了MySQL、DB2和Oracle的差异。存储过程和索引的使用及优化方法也被讨论，包括索引的优缺点、类型和数据结构。最后，文章介绍了数据库优化策略和数据库设计的范式，以及分库分表的实践与优缺点。

摘要由CSDN通过智能技术生成

六、mysql、DB2和Oracle的区别

一、四大特性

原子性（Atomicity）：是指事务包含的所有操作要么全部成功，要么全部失败回滚。失败回滚的操作事务，将不能对事务有任何影响
一致性（Consistency）：是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。具体表现为一致读和一致写，就是说如果事务中读取数据一定是从一个状态中读取的，不能是一部分是从改变前的状态，一部分是从改变后的状态中读取的
隔离性（Isolation）：当多个用户并发访问数据库时，比如同时访问一张表，数据库每一个用户开启的事务，不能被其他事务所做的操作干扰，多个并发事务之间，应当相互隔离
持久性（Durability）：事务的操作，一旦提交，对于数据库中数据的改变是永久性的

二、隔离级别

1、数据库的并发问题

数据库有可能同时被多个用户访问，在多个用户同时操作的情况下，就可能出现以下的问题：

1）脏读

指一个事务读取到另一个事务未提交的数据。

2）不可重复读

指一个事务对同一行数据重复读取两次，但得到的结果不同。

3）虚读/幻读

指一个事务执行两次查询，但第二次查询的结果包含了第一次查询中未出现的数据。

4）丢失更新

指两个事务同时更新一行数据，后提交（或撤销）的事务将之前事务提交的数据覆盖了。

丢失更新可分为两类，分别是第一类丢失更新和第二类丢失更新。

第一类丢失更新是指两个事务同时操作同一个数据时，当第一个事务撤销时，把已经提交的第二个事务的更新数据覆盖了，第二个事务就造成了数据丢失。
第二类丢失更新是指当两个事务同时操作同一个数据时，第一个事务将修改结果成功提交后，对第二个事务已经提交的修改结果进行了覆盖，对第二个事务造成了数据丢失。

2、四个隔离级别

（1）读未提交（Read Uncommitted）（脏读）

防止丢失更新
两个事务分别读和写，可以同时进行
不允许两个事务同时写

一个事务在执行过程中，既可以访问其他事务未提交的新插入的数据，又可以访问未提交的修改数据。如果一个事务已经开始写数据，则另外一个事务不允许同时进行写操作，但允许其他事务读此行数据。

此隔离级别

（2）读已提交（Read Commited）（oracle默认）

防止脏读
写的时候其他事务不允许读和写

一个事务在执行过程中，既可以访问其他事务成功提交的新插入的数据，又可以访问成功修改的数据。读取数据的事务允许其他事务继续访问该行数据，但是未提交的写事务将会禁止其他事务访问该行

（3）可重复读（Repeatable Read）（mysql默认）

防止不可重复读和脏读
读的时候不允许其他事务写

一个事务在执行过程中，可以访问其他事务成功提交的新插入的数据，但不可以访问成功修改的数据。读取数据的事务将会禁止写事务（但允许读事务），写事务则禁止任何其他事务

（4）可串行化（Serializable ）

防止脏读、不可重复读和幻读
两个事务完全不能并发执行，只能一个接一个进行

提供严格的事务隔离。它要求事务序列化执行，事务只能一个接着一个地执行，不能并发执行。此隔离级别可有效防止脏读、不可重复读和幻读。但这个级别可能导致大量的超时现象和锁竞争，在实际应用中很少使用

一般来说，事务的隔离级别越高，越能保证数据库的完整性和一致性，但相对来说，隔离级别越高，对并发性能的影响也越大。因此，通常将数据库的隔离级别设置为 Read Committed，即读已提交数据，它既能防止脏读，又能有较好的并发性能。虽然这种隔离级别会导致不可重复读、幻读和第二类丢失更新这些并发问题，但可通过在应用程序中采用悲观锁和乐观锁加以控制。

3、悲观锁和乐观锁

（1）两种锁介绍

悲观锁

总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现，适用于多写的情况
对读写都加锁

乐观锁

总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量
读不加锁，写加锁

（2）适用场景

两种锁各有优缺点，不能说一种好于另一种

乐观锁适用于写比较少的情况下（多读场景），即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果是多写的情况，一般会经常产生冲突，这就会导致上层应用会不断的进行retry，这样反倒是降低了性能，所以一般多写的场景下用悲观锁就比较合适。

一个典型的悲观锁调用：

select * from student where name="张三" for update

（3）乐观锁的实现方式

有两种方式：

版本号机制

在数据表中加上一个 version 字段来实现的，表示数据被修改的次数，当执行写操作并且写入成功后，version = version + 1，当线程A要更新数据时，在读取数据的同时也会读取 version 值，在提交更新时，若刚才读取到的 version 值为当前数据库中的version值相等时才更新，否则重试更新操作，直到更新成功

CAS算法

这是一种有名的无锁算法，涉及到三个操作数

需要读写的内存值 V

进行比较的值 A

拟写入的新值 B

当且仅当 V 的值等于 A时，CAS通过原子方式用新值B来更新V的值，否则不会执行任何操作（比较和替换是一个原子操作）。一般情况下是一个自旋操作，即不断的重试

CAS算法有两个常见问题

一是ABA 问题
如果一个变量V初次读取的时候是A值，并且在准备赋值的时候检查到它仍然是A值，那我们就能说明它的值没有被其他线程修改过了吗？很明显是不能的，因为在这段时间它的值可能被改为其他值，然后又改回A，那CAS操作就会误认为它从来没有被修改过。这个问题被称为CAS操作的 "ABA"问题。
二是循环时间长开销大
自旋CAS（也就是不成功就一直循环执行直到成功）如果长时间不成功，会给CPU带来非常大的执行开销。如果JVM能支持处理器提供的pause指令那么效率会有一定的提升，pause指令有两个作用，第一它可以延迟流水线执行指令（de-pipeline）,使CPU不会消耗过多的执行资源，延迟的时间取决于具体实现的版本，在一些处理器上延迟时间是零。第二它可以避免在退出循环的时候因内存顺序冲突（memory order violation）而引起CPU流水线被清空（CPU pipeline flush），从而提高CPU的执行效率