一 . 事务的四个特性？
四大特性是：ACID 原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）+介绍四个特性概念；
原子性：整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
一致性：在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。
隔离性：当两个或者多个事务并发访问（此处访问指查询和修改的操作）数据库的同一数据时所表现出的互相关系。事务隔离分为不同的级别，包括读未提交（Read uncommitted）、读提交（Read committed）、可重复读（Repeatable read）和串行化（Serializable）。隔离状态执行事务，使它们好像是系统在给定时间内执行的唯一操作。如果有两个事务，运行在相同的时间内，执行 相同的功能，事务的隔离性将确保每一事务在系统中认为只有该事务在使用系统。这种属性有时称为串行化，为了防止事务操作间的混淆，必须串行化或序列化请求，使得在同一时间仅有一个请求用于同一数据。
持久性：在事务完成以后，该事务对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。
二 . 事务的隔离级别
读未提交（Read uncommitted）、读已提交（Read committed）、可重复读（Repeatable read）和串行化（Serializable）
① Serializable (串行化)：可避免脏读、不可重复读、幻读的发生。
SERIALIZABLE可以防止除更新丢失外所有的一致性问题,即:
1.语句无法读取其它事务已修改但未提交的记录。
2.在当前事务完成之前，其它事务不能修改目前事务已读取的记录。
3.在当前事务完成之前，其它事务所插入的新记录，其索引键值不能在当前事务的任何语句所读取的索引键范围中。
② Repeatable read (可重复读)：可避免脏读、不可重复读的发生。
REPEATABLE READ事务不会产生脏读，并且在事务完成之前，任何其它事务都不能修改目前事务已读取的记录（这一点和串行化一样）。其它事务仍可以插入新记录，但必须符合当前事务的搜索条件——这意味着当前事务重新查询记录时，会产生幻读（Phantom Read）。
③ Read committed (读已提交)：可避免脏读的发生。
语句无法读取其它事务已修改但未提交的记录。（这一点 和串行化一样）
④ Read uncommitted (读未提交)：最低级别，任何情况都无法保证。
三. 四大冲突问题
1、脏读
某个事务读取的数据是另一个事务正在处理的数据。而另一个事务可能会回滚，造成第一个事务读取的数据是错误的。
2、不可重复读
在一个事务里两次读入数据，但另一个事务已经更改了第一个事务涉及到的数据，造成第一个事务读入旧数据。
3、幻读
幻读是指当事务不是独立执行时发生的一种现象。例如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好象发生了幻觉一样。
4、更新丢失
多个事务同时读取某一数据，一个事务成功处理好了数据，被另一个事务写回原值，造成第一个事务更新丢失。
四。 乐观锁和悲观锁？使用场景？
乐观锁：默认读数据的时候不会修改，所以不会上锁；
悲观锁：默认读数据的时候会修改，所以会上锁；
乐观锁适用于多读少写的情况，省去锁的开销，加大系统的吞吐量。
五。 MySQL引擎的区别？
1).MyISAM是非事务安全型的，而InnoDB是事务安全型的。
2).MyISAM锁的粒度是表级，而InnoDB支持行级锁定。
3).MyISAM相对简单，所以在效率上要优于InnoDB，小型应用可以考虑使用MyISAM。
4).MyISAM管理非事务表。它提供高速存储和检索，以及全文搜索能力。如果应用中需要执行大量的SELECT查询，那么MyISAM是更好的选择。
5).InnoDB用于事务处理应用程序，具有众多特性，包括ACID事务支持。如果应用中需要执行大量的INSERT或UPDATE操作，则应该使用InnoDB，这样可以提高多用户并发操作的性能。由于锁的粒度更小，写操作不会锁定全表，所以在并发较高时，使用Innodb引擎会提升效率。
六。 数据库索引有哪些类型？
普通索引、唯一索引、主键索引、组合索引；
普通索引：没有任何限制；
唯一索引：索引列的值必须唯一，但允许有空值；
主键索引：特殊的唯一索引，不允许有空值；一个表只能有一个主键；
组合索引：多个字段组合作为索引；
七。 数据库索引原理？
索引：数据库索引，是数据库管理系统中一个排序的数据结构，以协助快速查询、更新数据库表中数据。索引的实现通常使用B树及其变种B+树。
在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据，这样就可以在这些数据结构上实现高级查找算法。这种数据结构，就是索引。
八。B树和B+树原理？
动态查找树主要有：二叉查找树（Binary Search Tree），平衡二叉查找树（Balanced Binary Search Tree），红黑树(Red-Black Tree )，B-tree/B+-tree/ B*-tree (B~Tree)。前三者是典型的二叉查找树结构，其查找的时间复杂度O(log2N)与树的深度相关，那么降低树的深度自然会提高查找效率。
但是咱们有面对这样一个实际问题：就是大规模数据存储中，实现索引查询这样一个实际背景下，树节点存储的元素数量是有限的（如果元素数量非常多的话，查找就退化成节点内部的线性查找了），这样导致二叉查找树结构由于树的深度过大而造成磁盘I/O读写过于频繁，进而导致查询效率低下（为什么会出现这种情况，待会在外部存储器-磁盘中有所解释），那么如何减少树的深度（当然是不能减少查询的数据量），一个基本的想法就是：采用多叉树结构（由于树节点元素数量是有限的，自然该节点的子树数量也就是有限的）。（解释为什么使用B树）
也就是说，因为磁盘的操作费时费资源，如果过于频繁的多次查找势必效率低下。那么如何提高效率，即如何避免磁盘过于频繁的多次查找呢？根据磁盘查找存取的次数往往由树的高度所决定，所以，只要我们通过某种较好的树结构减少树的结构尽量减少树的高度，那么是不是便能有效减少磁盘查找存取的次数呢？那这种有效的树结构是一种怎样的树呢？
这样我们就提出了一个新的查找树结构——多路查找树。根据平衡二叉树的启发，自然就想到平衡多路查找树结构，也就是这篇文章所要阐述的第一个主题B~tree，即B树结构(后面，我们将看到，B树的各种操作能使B树保持较低的高度，从而达到有效避免磁盘过于频繁的查找存取操作，从而有效提高查找效率)。
九。什么是B+树？（？？）
B+树是B树的变体，也是多路搜索树；B+树的特点是：
1）非叶子结点的子树指针P[i]，指向关键字值属于[K[i], K[i+1])的子树（B-树是开区间）
2）所有关键字都在叶子结点出现；
3）所有的非叶子节点相当于是叶子节点的索引；
4）为所有叶子结点增加一个链指针；
B+的搜索与B树也基本相同，区别是B+树只有达到叶子结点才命中（B-树可以在非叶子结点命中），其性能也等价于在关键字全集做一次二分查找；
B+树和B+树的区别：
1.所有关键字都出现在叶子结点的链表中（稠密索引），且链表中的关键字恰好是有序的；
2.只会在叶子结点命中；
3.非叶子结点相当于是叶子结点的索引（稀疏索引），叶子结点相当于是存储（关键字）数据的数据层；
B+树相比B树的优点：
(1) B+树改进了B树, 让内结点只作索引使用, 去掉了其中指向data的指针, 使得每个结点中能够存放更多的key, 这样访问叶节点的数据的磁盘读写次数就更低；
(2) 由于底部的叶子结点是链表形式, 因此也可以实现更方便的顺序遍历, 而B树则需要对整个树的每一层遍历，需要更多的磁盘读写；
十。 为什么用数据库连接池？
数据库连接池配置/驱动参数？如何防止失效？
url: 连接数据库的 URL
username: 登陆数据库所用的帐号
十一。
testOnReturn：返回对象时是否进行验证，检查对象是否有效，默认为false
testWhileIdle参数。这个参数为true时候，表示空闲时是进行验证，检查对象是否有效。然后minEvictableIdleTimeMillis配合timeBetweenEvictionRunsMillis，每过timeBetweenEvictionRunsMillis秒对连接池进行一次检测，将对象闲置时间超过minEvictableIdleTimeMillis秒的对象进行销毁，创建新的对象来取代。这样就能保证时刻都有正常的连接池对象存在。
转载参考：https://www.cnblogs.com/buwenyuwu/p/7222626.html?utm_source=itdadao&utm_medium=referral