标签：事务隔离级别 mvcc info 匹配 幻读 导致 脏读 完整性约束 事务隔离
面：如何设计一个关系型数据库？
这主要考察我们对关系型数据库整体架构的把握，相当于让我们自己编写一个RDBMS（关系型数据库管理系统）。设计架构图如下,可以从下图中的各个模块进行回答。
面：为什么要使用索引？
答：为了在数据库中记录较多的时候避免每次查询都用全表扫描的方式，我们需要一种更高效的机制，那就是索引类似与字典中的目录，用来快速查询数据。
面：什么样的信息能成为索引？
答：能将某个记录限定在一定查找范围内的字段，就是一些关键信息，如主键、唯一键以及普通键等。
为了提高索引的性能，就要采取一些数据结构来加快索引的查询。索引可以采用的数据结构主要有以下几种：
二叉查找树的弊端：当对索引的数据结构进行修改后，可能会退化成链表，即时间复杂度从O（logn）降低到O（n）。即使通过旋转等方式使此树能够保证二叉查找树的结构，那么还有一个影响性能的关键因素：I/O读写。深度过深的话，I/O读写次数也会变多，效率还是很低。所以二叉查找树不适用于建立索引。
B-Tree：通过分析二叉查找树的弊端，我们可以降低树的高度来减少I/O的次数。那么B-Tree就可以派上用场了。先看下什么是B-Tree，这里的B表示balance（平衡），B-Tree是一种多路自平衡的搜索树。它类似于普通的平衡二叉树，不同的一点是B-Tree允许每个节点有更多的子节点。下图是B-Tree的简化图：
B-Tree有以下特点：
B+-Tree：B+-Tree是B-Tree的变体，也是一种多路搜索树，它与B-Tree的不同之处在于：
简化B+-Tree如下图：
面：为什么B+-Tree相比B-Tree更适合用来做存储索引？
由于B+-Tree的查询必须进过根节点到叶子节点，经过多次I/O,那么是否可考虑Hash索引呢？
虽然Hash索引的查询效率比B+-Tree索引的查询效率要高，但同时它也有许多的弊端：
所以综上，MySQL采用B+树来作为索引的数据结构。
面：密集索引和稀疏索引的区别
答：
在MySQL中的InnoDB中，关于密集索引的知识点如下：
面：如何定位并优化慢查询SQL？（开放性）
答：
实例：首先查看慢日志（DML SQL执行时间大于一定长度）的相关配置。
show VARIABLES like '%query%'在返回的结果中，关注三个变量：
| Variable_name | value |
|---|---|
| long_query_time | 1.000000 #慢查询时间的阈值 |
| slow_query_log | ON #是否开启记录慢查询日志 |
| slow_query_log_file | /home/mysql/data3001/mysql/slow_query.log #慢日志路径 |
show status like '%slow_queries%' #查看当前慢查询的条数运行语句SELECT name FROM chapter,chpater表中有50多万条记录，耗时23s。运行上面的查询慢查询条数的SQL语句，会发现增加了1，接下来通过explain工具分析。运行语句explain SELECT name FROM chapter,关注返回结果的type列发现结果是ALL，意味着是走的全表扫描，那么确实是不快的。我们来看下查询走索引的，explain SELECT id FROM chapter,type列的结果是index，走的是索引（但不是主键索引，看key列结果是fk_chapter_novel，走的是外键索引，说明主键索引不一定比其他索引快）。此时运行SELECT id FROM chapte只耗时2.9秒。来强制走下主键索引，运行语句SELECT id FROM chapter FORCE INDEX(PRIMARY),耗时23s，运行EXPLAIN SELECT id FROM chapter FORCE INDEX(PRIMARY)发现是走了主键索引的，但是耗时却和全表扫描差不多了。
面：索引是建立的越多越好吗？
答：答案当然是否定的。
关于数据库锁部分主要回答如下问题：
面：MyISAM与InnoDB关于锁方面的区别是什么？
答：
共享锁和排它锁的兼容性
| - | X | S |
|---|---|---|
| X | 冲突 | 冲突 |
| S | 冲突 | 兼容 |
MyISAM适合的场景
InnoDB适合的场景
数据库锁的分类
面：数据库事务的四大特性
答：ACID
面：能说说事务隔离级别以及各级别下的并发访问问题吗？
答：MySQL事务的隔离级别由低到高分别是read uncommitted（未提交读）、read committed（提交读）、repeatable read（可重复读）、serializable（串行化）。并发访问问题及对应解决的事务隔离级别如下：
更新丢失（一个事务的更新覆盖掉了另一个事务的更新）：MySQL中所有事务隔离级别在数据库层面上均可避免
实例如下图：
脏读（一个事务读到另外一个未提交事务的数据）：READ-COMMITTED事务隔离级别及以上可避免
不可重复读（事务A多次读取同一数据，事务B在事务A读取的同时对该数据做了更新并提交，导致事务A多次读取到的结果不一致）：REPEATABLE-READ事务隔离级别及以上可避免
幻读（事务A多次读取与搜索条件相匹配的若干行，事务B用插入或删除行的方式来修改事务A的结果集，导致事务A出现了“幻觉”）：SERIALIZABLE事务隔离级别可避免
当前读与快照读
当前读的数据是最新的，而快照读读取的是快照。当前读主要是以下SQL：
select...lock in share mode
select...for update
update,delete,insert面：能说说InnoDB可重复读隔离级别下如何避免幻读吗？
答：表面上来看是通过伪MVCC的快照读（非阻塞读）实现的，但本质确实通过next-key锁即行锁+gap锁实现的。
标签：事务隔离级别 mvcc info 匹配 幻读 导致 脏读 完整性约束 事务隔离
原文地址：https://www.cnblogs.com/yunche/p/10546627.html
