数据库面试问题整理

Posted 2022-04-16 ITAK

1. 事务

事务就是一组原子性的SQL操作或者一个独立的工作单元，事务内的语句要么全部执行成功，要么全部执行失败。事务是指对系统进行的一组操作，为了保证系统的完整性，事务需要具有ACID特性，具体如下：

1.1 原子性（Atomic）

一个事务包含多个操作，这些操作要么全部执行，要么全都不执行。实现事务的原子性，要支持回滚操作，在某个操作失败后，回滚到事务执行之前的状态。 回滚实际上是一个比较高层抽象的概念，大多数DB在实现事务时，是在事务操作的数据快照上进行的（比如，MVCC），并不修改实际的数据，如果有错并不会提交，所以很自然的支持回滚。 而在其他支持简单事务的系统中，不会在快照上更新，而直接操作实际数据。可以先预演一边所有要执行的操作，如果失败则这些操作不会被执行，通过这种方式很简单的实现了原子性。

1.2 一致性（Consistency）

一致性是指事务使得系统从一个一致的状态转换到另一个一致状态。事务的一致性决定了一个系统设计和实现的复杂度，也导致了事务的不同隔离级别。事务可以不同程度的一致性：强一致性：读操作可以立即读到提交的更新操作。弱一致性：提交的更新操作，不一定立即会被读操作读到，此种情况会存在一个不一致窗口，指的是读操作可以读到最新值的一段时间。最终一致性：是弱一致性的特例。事务更新一份数据，最终一致性保证在没有其他事务更新同样的值的话，最终所有的事务都会读到之前事务更新的最新值。如果没有错误发生，不一致窗口的大小依赖于：通信延迟，系统负载等。 其他一致性变体还有：单调一致性：如果一个进程已经读到一个值，那么后续不会读到更早的值。会话一致性：保证客户端和服务器交互的会话过程中，读操作可以读到更新操作后的最新值。

1.3 隔离性（Isolation）

并发事务之间互相影响的程度，比如一个事务会不会读取到另一个未提交的事务修改的数据。在事务并发操作时，可能出现的问题有：
脏读：事务A修改了一个数据，但未提交，事务B读到了事务A未提交的更新结果，如果事务A提交失败，事务B读到的就是脏数据。
**不可重复读：**在同一个事务中，对于同一份数据读取到的结果不一致。比如，事务B在事务A提交前读到的结果，和提交后读到的结果可能不同。不可重复读出现的原因就是事务并发修改记录，要避免这种情况，最简单的方法就是对要修改的记录加锁，这回导致锁竞争加剧，影响性能。另一种方法是通过MVCC可以在无锁的情况下，避免不可重复读。
幻读：在同一个事务中，同一个查询多次返回的结果不一致。事务A新增了一条记录，事务B在事务A提交前后各执行了一次查询操作，发现后一次比前一次多了一条记录。幻读是由于并发事务增加记录导致的，这个不能像不可重复读通过记录加锁解决，因为对于新增的记录根本无法加锁。需要将事务串行化，才能避免幻读。
事务的隔离级别从低到高有：
Read Uncommitted：最低的隔离级别，什么都不需要做，一个事务可以读到另一个事务未提交的结果。所有的并发事务问题都会发生。
Read Committed：只有在事务提交后，其更新结果才会被其他事务看见。可以解决脏读问题。Repeated Read：在一个事务中，对于同一份数据的读取结果总是相同的，无论是否有其他事务对这份数据进行操作，以及这个事务是否提交。可以解决脏读、不可重复读。
Serialization：事务串行化执行，隔离级别最高，牺牲了系统的并发性。可以解决并发事务的所有问题。 通常，在工程实践中，为了性能的考虑会对隔离性进行折中。

1.4 持久性（Durability）

事务提交后，对系统的影响是永久的。

2. MyISAM与InnoDB区别

详细的区别

3. MongoDB和mysql的区别

mongo优势：
1、在适量级的内存的MongoDB的性能是非常迅速的，它将热数据存储在物理内存中，使得热数据的读写变得十分快。
2、MongoDB的高可用和集群架构拥有十分高的扩展性。
3、在副本集中，当主库遇到问题，无法继续提供服务的时候，副本集将选举一个新的主库继续提供服务。
4、MongoDB的Bson和JSon格式的数据十分适合文档格式的存储与查询。
区别如下：
数据库模型 非关系型 关系型
存储方式 以类JSON的文档的格式存储 不同引擎有不同的存储方式
查询语句 MongoDB查询方式（类似javascript的函数） SQL语句
数据处理方式 基于内存，将热数据存放在物理内存中，从而达到高速读写 不同引擎有自己的特点
占用空间 占用空间大 占用空间小
join操作 MongoDB没有join MySQL支持join

4. 索引

概念：对数据库表列进行增加恰当索引，可以快速的找到匹配的记录行数，相比于默认的全表扫描，可以大大加快查找的速度。
作用：加快查找速度；
实现方法：一般分为B+树索引和哈希索引。
B+树索引：在B-tree上改进得到，其非叶子节点均为key值，叶子节点是key-data键值对。叶子节点前后相连且有序。
哈希索引：通过对key进行hash(crc/MD5/sha1/sha256…)而将记录存储在不同的bucket种，可以做到常数时间的查找，但要注意哈希冲突的避免（链表法、线性探测、二次探测、公共溢出区的方法）。其中MD5 128位，和sha1/256码都较长不太适合作为hash函数。默认无序。
为什么有了B+树索引还要hash索引？
B+树默认有序，hash默认无序，所以哈希索引无法用于排序；
哈希索引O(1)在速度上毋庸置疑要快于B+树近似O(logn);
哈希索引只能进行等值查询（因为他要计算hash(key)再去匹配）而B+树索引可以进行等值、部分前缀、范围查询；
底层实现结构不同：B+树是非线性结构，hash桶是线性结构。
对于某些场景如热点页/活跃查询页，需要借助哈希索引来实现快速查询。
索引越多越快？
此言差矣，索引并非是虚无缥缈的，是实实在在的一种数据结构（B+树/hash桶）要占内存、维护它要系统开销，一般的插入删除都要进行结构的调整，这要消耗时间，所以索引太多反而拖慢查找时间。有时候，见数据量不多时，建立索引还不如全表查询。索引加快了检索的速度，但是插入删除修改都需要DBMS动态更新内部索引结构，要耗费开销。

5. InnoDB 的MVCC

多版本并发控制，是为了避免加锁而实现的。一般的实现方法是存储快照来实现的。InnoDB实现方式是在记录后添加两个隐藏列（表项），分别是事务创建时间、过期时间，存储的实际上是系统版本号（系统版本号随着事务的创建而递增）。
这样一来，INSERT 时加上开始版本号，UPDATE/DELETE时加上过期版本号，这样一来在SELETE时，就只访问开始系统版本号小于当前的事务的版本号、过期时间要么未定义要么在当前版本号之后的记录，这样就可以保证：访问的记录是在本事务开始前就存在而且在本事务期间没有过期（被删除或被修改过的）。

6. SQL优化

1. 在经常性的检索列上，建立必要索引，以加快搜索速率，避免全表扫描（索引覆盖扫描）；
2. 多次查询同样的数据，可以考虑缓存该组数据；
3. 审视select * form tables, 你需要所有列数据吗？
4. 切分查询（大查询切分成为小查询，避免一次性锁住大量数据）
5. 分解关联查询（单表查询，结果在应用程序中进行关联，可以减少处理过程中的锁争用）
6. 尽量先做单表查询；

7. 视图

7.1 概念

视图是一个虚拟表，其内容由查询定义。同真实的表一样，视图包含一系列带有名称的列和行数据。但是，视图并不在数据库中以存储的数据值集形式存在。

7.2 优点:

1. 使用视图，可以定制用户数据，聚焦特定的数据。
   解释：在实际过程中，公司有不同角色的工作人员，我们以销售公司为例的话，采购人员，可以需要一些与其有关的数据，而与他无关的数据，对他没有任何意义，我们可以根据这一实际情况，专门为采购人员创建一个视图，以后他在查询数据时，只需select * from view_caigou 就可以啦。
2. 使用视图，可以简化数据操作。
   解释：我们在使用查询时，在很多时候我们要使用聚合函数，同时还要显示其它字段的信息，可能还会需要关联到其它表，这时写的语句可能会很长，如果这个动作频繁发生的话，我们可以创建视图，这以后，我们只需要select * from view1就可以啦，这样很方便。
3. 使用视图，基表中的数据就有了一定的安全性
   解释：因为视图是虚拟的，物理上是不存在的，只是存储了数据的集合，我们可以将基表中重要的字段信息，可以不通过视图给用户，视图是动态的数据的集合，数据是随着基表的更新而更新。同时，用户对视图，不可以随意的更改和删除，可以保证数据的安全性。
4. 可以合并分离的数据，创建分区视图
   解释：随着社会的发展，公司的业务量的不断的扩大，一个大公司，下属都设有很多的分公司，为了管理方便，我们需要统一表的结构，定期查看各公司业务情况，而分别看各个公司的数据很不方便，没有很好的可比性，如果将这些数据合并为一个表格里，就方便多啦，这时我们就可以使用union关键字，将各分公司的数据合并为一个视图。

7.3 缺点:

1. 性能差　　
   必须把视图查询转化成对基本表的查询，如果这个视图是由一个复杂的多表查询所定义，那么，即使是视图的一个简单查询，也要把它变成一个复杂的结合体，需要花费一定的时间。
2. 修改限制　　
   当用户试图修改试图的某些信息时，数据库必须把它转化为对基本表的某些信息的修改，对于简单的试图来说，这是很方便的，但是，对于比较复杂的试图，可能是不可修改的。