数据库（面试向）

目录

一、四大特性

二、隔离级别

1、数据库的并发问题

2、四个隔离级别

3、悲观锁和乐观锁

三、查询语句中的执行顺序

四、视图&临时表&子查询

五、主从复制

1、原理

2、策略

3、搭建

4、优势

六、mysql、DB2和Oracle的区别

七、存储过程

八、索引

1、优缺点

2、需要建索引的情况

3、不建议建索引的情况

4、索引有哪几类

5、索引的数据结构有哪些

九、数据库的优化

1、表结构优化

2、查询方式优化

3、什么情况下不适合建索引？

4、组合索引失效的情况

十、PLSQL查看数据库的执行计划：

十一、数据库三范式

十二、分库分表

---

一、四大特性

• 原子性（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的执行效率

三、查询语句中的执行顺序

查询中用到的关键词主要包含六个，并且他们的顺序依次为 ：

select--from--where--group by--having--order by

• from:需要从哪个数据表检索数据
• where:过滤表中数据的条件
• group by:如何将上面过滤出的数据分组
• having:对上面已经分组的数据进行过滤的条件
• select:查看结果集中的哪个列，或列的计算结果
• order by :按照什么样的顺序来查看返回的数据

注：

from后面的表关联，是自右向左解析 而where条件的解析顺序是自下而上的。

也就是说，在写SQL文的时候，尽量把数据量小的表放在最右边来进行关联（用小表去匹配大表），