这篇文章主要介绍了Java中关于数据库的面试题有哪些，具有一定借鉴价值，感兴趣的朋友可以参考下，希望大家阅读完这篇文章之后大有收获，下面让小编带着大家一起了解一下。
面试题1：说一下你对聚集索引与非聚集索引的理解，以及他们的区别？
首先解释一下，什么是聚集索引和非聚集索引。这里我想起网上看到的一个典型的例子:
说索引像一个汉语字典，聚集索引是根据拼音查询，而非聚集索引是根据偏旁部首查询，你想想哪个查的快?
汉语字典的正文本身就是一个聚集索引。比如，我们要查“啊”字，拼音是“a”，按照拼音排序是以“a”开头“z”结尾的，那么“啊”字就自然地排在字典的前部。如果翻完了所有以“a”开头的内容仍然找不到这个字，那么就说明字典中就没有这个字。我们知道，其实字典的正文部分本身就是一个目录，不需要再去查其他目录来找到我们需要找的内容。我们把这种正文内容本身就按照一定规则排列（有序）的目录称为“聚集索引”。
问题来了，遇到不认识的字，不知道它的发音，怎么办？
这时候，就得用“偏旁部首”查了吧，然后根据这个偏旁后的页码来找字。这种结合“部首目录”和“检字表”查到的字的排序并不是真正的正文的排序方法，比如查“张”字，我们可以看到在查部首之后的检字表中“张”的页码是672页，检字表中“张”的上面是“驰”字，但页码却是63页，“张”的下面是“弩”字，页面是390页。很显然，这些字并不是真正的分别位于“张”字的上下方，现在看到的连续的“驰、张、弩”三字实际上就是他们在非聚集索引中的排序，是字典正文中的字在非聚集索引中的映射。
我们可以通过这种方式来找到我们所需要的字，但它需要两个过程，先找到目录中的结果，然后再翻到相应页码。我们把这种目录纯粹是目录，正文纯粹是正文的排序方式（无序）称为“非聚集索引”。
1、聚集索引
聚集索引是我们常用的一种索引，该索引中键值的逻辑顺序决定了表中相应行的物理顺序，我们叶子结点直接对应的实际数据，当索引值唯一（unique）时，使用聚集索引查找特定的行效率很高。例如，使用唯一店员 ID 列 emp_id 查找特定雇员的最快速的方法，是在 emp_id 列上创建聚集索引或 PRIMARY KEY 约束。可见，自增主键就是一个标准的聚集索引。
当某列满足两个条件时，我们可以创建聚集索引：
数据存储有序（如自增）
key值应当唯一
聚簇索引像字典，字典按字母顺序排列数据，有序。在聚集索引中，索引包含指向数据存储的块而不是数据存储地址的指针，和非聚集索引（Normal）相反。
2、非聚集索引
非聚集索引就是索引类型为Normal的普通索引啦，我们在《聊聊MySQL索引“B+Tree”的前世今生》这篇文章中提到，B+Tree（这里是索引类型是Normal）所有关键字存储在叶子节点，但不存储真正的data，叶子结点存的是一个指向磁盘data的指针，需要到磁盘数据页中取。
非聚集索引的数据存储在一个位置，索引存储在另一位置。由于数据和非聚集索引是分开存储的，因此在一个表中可以有多个非聚集索引。
聚集索引 和 非聚集索引的区别：
单表中只能有一个聚集索引，而非聚集索引单表可以存在多个。
聚集索引，索引中键值的逻辑顺序决定了表中相应行的物理顺序；非聚集索引，索引中索引的逻辑顺序与磁盘上行的物理存储顺序不同。
索引是通过二叉树的数据结构来描述的，我们可以这么理解聚簇索引：索引的叶节点就是数据节点。而非聚簇索引的叶节点仍然是索引节点，只不过有一个指针指向对应的数据块。
聚集索引：物理存储按照索引排序；非聚集索引：物理存储不按照索引排序；
追问1：为什么聚集索引可以创建在任何一列上，如果此表没有主键约束，即有可能存在重复行数据呢？
乍一看，这还真是和聚集索引的约束相背，但实际情况真可以创建聚集索引。
其原因是：如果未使用 UNIQUE 属性创建聚集索引，数据库引擎将向表自动添加一个四字节 uniqueifier列。必要时，数据库引擎 将向行自动添加一个 uniqueifier 值，使每个键唯一。此列和列值供内部使用，用户不能查看或访问。
追问2：聚集索引一定比非聚集索引性能优么？
如果想查询学分在60-90之间的学生的学分以及姓名，在学分上创建聚集索引是否是最优的呢？
并不是。既然只输出两列，我们可以在学分以及学生姓名上创建联合非聚集索引，此时的索引就形成了覆盖索引，即索引所存储的内容就是最终输出的数据，这种索引当然比以学分为聚集索引做查询性能好，算是相当于联合聚集索引~~灵活运用即可。
面试题2：说一说你对 B树 和 B+树 的理解吧
1、B树（Balanced Tree）多路平衡查找树 多叉
B树是一种多路自平衡搜索树，它类似普通的二叉树，但是B书允许每个节点有更多的子节点。B树示意图如下：值得注意的是，B树的非叶子节点和叶子结点的data数据都是分开存储的，那么针对范围查询、排序等常用特性就很不友好了。
B树的特点：
所有键值分布在整个树中
任何关键字出现且只出现在一个节点中
搜索有可能在非叶子节点结束
在关键字全集内做一次查找，性能逼近二分查找算法
为了提升效率，要尽量减少磁盘I/O的次数。实际过程中，磁盘并不是每次严格按需读取，而是每次都会预读。
磁盘读取完需要的数据后，会按顺序再多读一部分数据到内存中，这样做的理论依据是计算机科学中注明的局部性原理：
由于磁盘顺序读取的效率很高(不需要寻址时间，只需很少的旋转时间)，因此对于具有局部性的程序来说，预读可以提高I/O效率.预读的长度一般为页(page)的整倍数。
MySQL(默认使用InnoDB引擎)，将记录按照页的方式进行管理，每页大小默认为16K(可以修改)。
B-Tree借助计算机磁盘预读机制:
每次新建节点的时候，都是申请一个页的空间，所以每查找一个节点只需要一次I/O;因为实际应用当中，节点深度会很少，所以查找效率很高.
2、B+ Tree (B+树是B树的变体，也是一种多路搜索树)
从图中也可以看到，B+树与B树的不同在于：
所有关键字存储在叶子节点，非叶子节点不存储真正的data，从而可以快速定位到叶子结点。
为所有叶子节点增加了一个链指针，意味着所有的值都是按顺序存储的，并且每一个叶子页到根的距离相同，很适合查找范围数据。说明支持范围查询和天然排序。
因此，B+Tree可以对<，<=，=，>，>=，BETWEEN，IN，以及不以通配符开始的LIKE使用索引。且如果用到了该索引，排序功能的消耗大大减少。
B+树的优点：
比较的次数均衡，减少了I/O次数，提高了查找速度，查找也更稳定。
B+树的磁盘读写代价更低
B+树的查询效率更加稳定
要知道的是，你每次创建表，系统会为你自动创建一个基于ID的聚集索引（上述B+树），存储全部数据；你每次增加索引，数据库就会为你创建一个附加索引（上述B+树），索引选取的字段个数就是每个节点存储数据索引的个数，注意该索引并不存储全部数据。
面试题3：说一下你对最左前缀原则的理解吧
通常我们在建立联合索引的时候，相信建立过索引的同学们会发现，无论是Oracle还是 MySQL 都会让我们选择索引的顺序，比如我们想在a,b,c三个字段上建立一个联合索引，我们可以选择自己想要的优先级，(a、b、c)，或是 (b、a、c) 或者是(c、a、b) 等顺序。
为什么数据库会让我们选择字段的顺序呢？不都是三个字段的联合索引么？这里就引出了数据库索引的最重要的原则之一，最左匹配原则。
在我们开发中经常会遇到这种问题，明明这个字段建了联合索引，但是SQL查询该字段时却不会使用这个索引。难道这索引是假的？白嫖老子资源？！
比如索引abc_index:(a,b,c)是a,b,c三个字段的联合索引，下列sql执行时都无法命中索引abc_index；
select * from table where c = '1';select * from table where b ='1' and c ='2';以下三种情况却会走索引:
select * from table where a = '1';select * from table where a = '1' and b = '2';select * from table where a = '1' and b = '2' and c='3';从上面两个例子大家有木有看出点眉目呢？
是的，索引abc_index:(a,b,c)，只会在where条件中带有(a)、(a,b)、(a,b,c)的三种类型的查询中使用。其实这里说的有一点歧义，其实当where条件只有(a,c)时也会走，但是只走a字段索引，不会走c字段。
那么这都是为什么呢？我们一起来看看其原理吧。
一、最左匹配原则的原理
MySQL 建立多列索引（联合索引）有最左匹配的原则，即最左优先：
如果有一个 2 列的索引 (a, b)，则已经对 (a)、(a, b) 上建立了索引；
如果有一个 3 列索引 (a, b, c)，则已经对 (a)、(a, b)、(a, b, c) 上建立了索引；
假设数据 表 LOL (id,sex,price,name) 的物理位置（表中的无序数据）如下：
（注：下面数据是测试少量数据选用的，只为了方便大家看清楚。实际操作中，应按照使用频率、数据区分度来综合设定索引顺序~）
主键id sex(a) price(b) name(c) (1) 1 1350 AAA安妮(2) 2 6300 MMM盲僧(3) 1 3150 NNN奈德丽(4) 2 6300 CCC锤石(5) 1 6300 LLL龙女(6) 2 3150 EEE伊泽瑞尔(7) 2 6300 III艾克(8) 1 6300 BBB暴走萝莉(9) 1 4800 FFF发条魔灵(10) 2 3150 KKK卡牌大师(11) 1 450 HHH寒冰射手(12) 2 450 GGG盖伦(13) 2 3150 OOO小提莫(14) 2 3150 DDD刀锋之影(15) 2 6300 JJJ疾风剑豪(16) 2 450 JJJ剑圣当你在LOL表创建一个联合索引 abc_index:(sex,price,name)时，生成的索引文件逻辑上等同于下表内容（分级排序）：
sex(a) price(b) name(c) 主键id1 450 HHH寒冰射手 (11)1 1350 AAA安妮 (1)1 3150 NNN奈德丽 (3)1 4800 FFF发条魔灵 (9)1 6300 BBB暴走萝莉 (8)1 6300 LLL龙女 (5)2 450 GGG盖伦 (12)2 450 JJJ剑圣 (16)2 3150 DDD刀锋之影 (14)2 3150 EEE伊泽瑞尔 (6)2 3150 KKK卡牌大师 (10)2 3150 OOO小提莫 (13)2 6300 CCC锤石 (4)2 6300 III艾克 (7)2 6300 JJJ疾风剑豪 (15)2 6300 MMM盲僧 (2)小伙伴儿们有没有发现B+树联合索引的规律？感觉还有点模糊的话，那咱们再来看一张索引存储数据的结构图，或许更明了一些。
这是一张来自思否上的图片，层次感很清晰，小伙伴可以看到，对于B+树中的联合索引，每级索引都是排好序的。联合索引 bcd_index:(b,c,d) , 在索引树中的样子如图 ， 在比较的过程中 ，先判断 b 再判断 c 然后是 d 。
由上图可以看出，B+ 树的数据项是复合的数据结构，同样，对于我们这张表的联合索引 (sex,price,name)来说 ，B+ 树也是按照从左到右的顺序来建立搜索树的，当SQL如下时：
select sex,price,name from LOL where sex = 2 and price = 6300 and name = 'JJJ疾风剑豪';B+ 树会优先比较 sex 来确定下一步的指针所搜方向，如果 sex 相同再依次比较 price 和 name，最后得到检索的数据；
二、违背最左原则导致索引失效的情况
（下面以联合索引 abc_index:(a,b,c) 来进行讲解，便于理解）
1、查询条件中，缺失优先级最高的索引 “a”
当 where b = 6300 and c = 'JJJ疾风剑豪' 这种没有以 a 为条件来检索时；B+树就不知道第一步该查哪个节点，从而需要去全表扫描了（即不走索引）。因为建立搜索树的时候 a 就是第一个比较因子，必须要先根据 a 来搜索，进而才能往后继续查询b 和 c，这点我们通过上面的存储结构图可以看明白。
2、查询条件中，缺失优先级居中的索引 “b”
当 where a =1 and c =“JJJ疾风剑豪” 这样的数据来检索时；B+ 树可以用 a 来指定第一步搜索方向，但由于下一个字段 b 的缺失，所以只能把 a = 1 的数据主键ID都找到，通过查到的主键ID回表查询相关行，再去匹配 c = ‘JJJ疾风剑豪' 的数据了，当然，这至少把 a = 1 的数据筛选出来了，总比直接全表扫描好多了。
这就是MySQL非常重要的原则，即索引的最左匹配原则。
三、查询优化器偷偷干了哪些事儿
当对索引中所有列通过"=" 或 “IN” 进行精确匹配时，索引都可以被用到。
1、如果建的索引顺序是 (a, b)。而查询的语句是 where b = 1 AND a = ‘陈哈哈'; 为什么还能利用到索引？
理论上索引对顺序是敏感的，但是由于 MySQL 的查询优化器会自动调整 where 子句的条件顺序以使用适合的索引，所以 MySQL 不存在 where 子句的顺序问题而造成索引失效。当然了，SQL书写的好习惯要保持，这也能让其他同事更好地理解你的SQL。
2、还有一个特殊情况说明下，下面这种类型的SQL， a 与 b 会走索引，c不会走。
select * from LOL where a = 2 and b > 1000 and c='JJJ疾风剑豪';对于上面这种类型的sql语句；mysql会一直向右匹配直到遇到范围查询(>、<、between、like)就停止匹配（包括like '陈%'这种）。在a、b走完索引后，c已经是无序了，所以c就没法走索引，优化器会认为还不如全表扫描c字段来的快。所以只使用了(a,b)两个索引，影响了执行效率。
其实，这种场景可以通过修改索引顺序为 abc_index:(a,c,b)，就可以使三个索引字段都用到索引，建议小伙伴们不要有问题就想着新增索引哦，浪费资源还增加服务器压力。
综上，如果通过调整顺序，就可以解决问题或少维护一个索引，那么这个顺序往往就是我们DBA人员需要优先考虑采用的。
感谢你能够认真阅读完这篇文章，希望小编分享的“Java中关于数据库的面试题有哪些”这篇文章对大家有帮助，同时也希望大家多多支持编程网，关注编程网行业资讯频道，更多相关知识等着你来学习!
