mysql面试题

– 面试题：
/*
一.视图作用是什么？好处有哪些？
1，简单性。看到的就是需要的。视图不仅可以简化用户对数据的理解，也可以简化他们的操作。 那些被经常使用的查询可以被定义为视图，从而使得用户不必为以后的操作每次指定全部的条件。

			2， 安全性。通过视图用户只能查询和修改他们所能见到的数据。但不能授权到数据库特定行和特定的列上。

			通过视图，用户可以被限制在数据的不同子集上：使用权限可被限制在另一视图的一个子集上，或是一些视图和基表合并后的子集上。

			3， 逻辑数据独立性。视图可帮助用户屏蔽真实表结构变化带来的影响。

二.索引的必要性有哪些？怎么合理添加索引？索引的优势？
1、表的主键、外键必须有索引；
2、数据量超过300的表应该有索引；
3、经常与其他表进行连接的表,在连接字段上应该建立索引；
4、经常出现在Where子句中的字段,特别是大表的字段,应该建立索引；
5、索引应该建在选择性高的字段上；
6、索引应该建在小字段上,对于大的文本字段甚至超长字段,不要建索引；
7、复合索引的建立需要进行仔细分析；尽量考虑用单字段索引代替：
A、正确选择复合索引中的主列字段,一般是选择性较好的字段；
B、复合索引的几个字段是否经常同时以AND方式出现在Where子句中?单字段查询是否极少甚至没有?如果是,则可以建立复合索引；否则考虑单字段索引；
C、如果复合索引中包含的字段经常单独出现在Where子句中,则分解为多个单字段索引；
D、如果复合索引所包含的字段超过3个,那么仔细考虑其必要性,考虑减少复合的字段；
E、如果既有单字段索引,又有这几个字段上的复合索引,一般可以删除复合索引；
8、频繁进行数据操作的表,不要建立太多的索引；
9、删除无用的索引,避免对执行计划造成负面影响；
以上是一些普遍的建立索引时的判断依据.一言以蔽之,索引的建立必须慎重,对每个索引的必要性都应该经过仔细分析,要有建立的依据.因为太多的索引与不充分、不正确的索引对性能都毫无益处：在表上建立的每个索引都会增加存储开销,索引对于插入、删除、更新操作也会增加处理上的开销.另外,过多的复合索引,在有单字段索引的情况下,一般都是没有存在价值的；相反,还会降低数据增加删除时的性能,特别是对频繁更新的表来说,负面影响更大.
三.索引的原理
四、索引的实现原理
MySQL支持诸多存储引擎，而各种存储引擎对索引的支持也各不相同，因此MySQL数据库支持多种索引类型，如BTree索引，B+Tree索引，哈希索引，全文索引等等，
1、哈希索引：
只有memory（内存）存储引擎支持哈希索引，哈希索引用索引列的值计算该值的hashCode，然后在hashCode相应的位置存执该值所在行数据的物理位置，因为使用散列算法，因此访问速度非常快，但是一个值只能对应一个hashCode，而且是散列的分布方式，因此哈希索引不支持范围查找和排序的功能。

2、全文索引：
FULLTEXT（全文）索引，仅可用于MyISAM和InnoDB，针对较大的数据，生成全文索引非常的消耗时间和空间。对于文本的大对象，或者较大的CHAR类型的数据，如果使用普通索引，那么匹配文本前几个字符还是可行的，但是想要匹配文本中间的几个单词，那么就要使用LIKE %word%来匹配，这样需要很长的时间来处理，响应时间会大大增加，这种情况，就可使用时FULLTEXT索引了，在生成FULLTEXT索引时，会为文本生成一份单词的清单，在索引时及根据这个单词的清单来索引。FULLTEXT可以在创建表的时候创建，也可以在需要的时候用ALTER或者CREATE INDEX来添加：

//创建表的时候添加FULLTEXT索引
CTREATE TABLE my_table(
id INT(10) PRIMARY KEY,
name VARCHAR(10) NOT NULL,
my_text TEXT,
FULLTEXT(my_text)
)ENGINE=MyISAM DEFAULT CHARSET=utf8;
//创建表以后，在需要的时候添加FULLTEXT索引
ALTER TABLE my_table ADD FULLTEXT INDEX ft_index(column_name);
全文索引的查询也有自己特殊的语法，而不能使用LIKE %查询字符串%的模糊查询语法

SELECT * FROM table_name MATCH(ft_index) AGAINST(‘查询字符串’);
注意：
*对于较大的数据集，把数据添加到一个没有FULLTEXT索引的表，然后添加FULLTEXT索引的速度比把数据添加到一个已经有FULLTEXT索引的表快。
*5.6版本前的MySQL自带的全文索引只能用于MyISAM存储引擎，如果是其它数据引擎，那么全文索引不会生效。5.6版本之后InnoDB存储引擎开始支持全文索引
*在MySQL中，全文索引支队英文有用，目前对中文还不支持。5.7版本之后通过使用ngram插件开始支持中文。
*在MySQL中，如果检索的字符串太短则无法检索得到预期的结果，检索的字符串长度至少为4字节，此外，如果检索的字符包括停止词，那么停止词会被忽略。

• 更深入的理解参考文章：全文索引的深入理解

3、BTree索引和B+Tree索引

BTree索引
BTree是平衡搜索多叉树，设树的度为2d（d>1），高度为h，那么BTree要满足以一下条件：

每个叶子结点的高度一样，等于h；
每个非叶子结点由n-1个key和n个指针point组成，其中d<=n<=2d,key和point相互间隔，结点两端一定是key；
叶子结点指针都为null；
非叶子结点的key都是[key,data]二元组，其中key表示作为索引的键，data为键值所在行的数据；
BTree的结构如下：

在BTree的机构下，就可以使用二分查找的查找方式，查找复杂度为h*log(n)，一般来说树的高度是很小的，一般为3左右，因此BTree是一个非常高效的查找结构。

BTree的查询、插入、删除过程可以参考：https://blog.csdn.net/endlu/article/details/51720299

B+Tree索引
B+Tree是BTree的一个变种，设d为树的度数，h为树的高度，B+Tree和BTree的不同主要在于：
B+Tree中的非叶子结点不存储数据，只存储键值；
B+Tree的叶子结点没有指针，所有键值都会出现在叶子结点上，且key存储的键值对应data数据的物理地址；
B+Tree的每个非叶子节点由n个键值key和n个指针point组成；
B+Tree的结构如下：
B+Tree对比BTree的优点：

1、磁盘读写代价更低

一般来说B+Tree比BTree更适合实现外存的索引结构，因为存储引擎的设计专家巧妙的利用了外存（磁盘）的存储结构，即磁盘的最小存储单位是扇区（sector），而操作系统的块（block）通常是整数倍的sector，操作系统以页（page）为单位管理内存，一页（page）通常默认为4K，数据库的页通常设置为操作系统页的整数倍，因此索引结构的节点被设计为一个页的大小，然后利用外存的“预读取”原则，每次读取的时候，把整个节点的数据读取到内存中，然后在内存中查找，已知内存的读取速度是外存读取I/O速度的几百倍，那么提升查找速度的关键就在于尽可能少的磁盘I/O，那么可以知道，每个节点中的key个数越多，那么树的高度越小，需要I/O的次数越少，因此一般来说B+Tree比BTree更快，因为B+Tree的非叶节点中不存储data，就可以存储更多的key。
2、查询速度更稳定

由于B+Tree非叶子节点不存储数据（data），因此所有的数据都要查询至叶子节点，而叶子节点的高度都是相同的，因此所有数据的查询速度都是一样的。

更多操作系统内容参考：

硬盘结构
扇区、块、簇、页的区别
操作系统层优化（进阶，初学不用看）带顺序索引的B+TREE
很多存储引擎在B+Tree的基础上进行了优化，添加了指向相邻叶节点的指针，形成了带有顺序访问指针的B+Tree，这样做是为了提高区间查找的效率，只要找到第一个值那么就可以顺序的查找后面的值。

B+Tree的结构如下：

聚簇索引和非聚簇索引

分析了MySQL的索引结构的实现原理，然后我们来看看具体的存储引擎怎么实现索引结构的，MySQL中最常见的两种存储引擎分别是MyISAM和InnoDB，分别实现了非聚簇索引和聚簇索引。

聚簇索引的解释是:聚簇索引的顺序就是数据的物理存储顺序

非聚簇索引的解释是:索引顺序与数据物理排列顺序无关

（这样说起来并不好理解，让人摸不着头脑，清继续看下文，并在插图下方对上述两句话有解释）

首先要介绍几个概念，在索引的分类中，我们可以按照索引的键是否为主键来分为“主索引”和“辅助索引”，使用主键键值建立的索引称为“主索引”，其它的称为“辅助索引”。因此主索引只能有一个，辅助索引可以有很多个。

MyISAM——非聚簇索引

MyISAM存储引擎采用的是非聚簇索引，非聚簇索引的主索引和辅助索引几乎是一样的，只是主索引不允许重复，不允许空值，他们的叶子结点的key都存储指向键值对应的数据的物理地址。
非聚簇索引的数据表和索引表是分开存储的。
非聚簇索引中的数据是根据数据的插入顺序保存。因此非聚簇索引更适合单个数据的查询。插入顺序不受键值影响。
只有在MyISAM中才能使用FULLTEXT索引。(mysql5.6以后innoDB也支持全文索引)
*最开始我一直不懂既然非聚簇索引的主索引和辅助索引指向相同的内容，为什么还要辅助索引这个东西呢，后来才明白索引不就是用来查询的吗，用在那些地方呢，不就是WHERE和ORDER BY 语句后面吗，那么如果查询的条件不是主键怎么办呢，这个时候就需要辅助索引了。

InnoDB——聚簇索引

聚簇索引的主索引的叶子结点存储的是键值对应的数据本身，辅助索引的叶子结点存储的是键值对应的数据的主键键值。因此主键的值长度越小越好，类型越简单越好。
聚簇索引的数据和主键索引存储在一起。
聚簇索引的数据是根据主键的顺序保存。因此适合按主键索引的区间查找，可以有更少的磁盘I/O，加快查询速度。但是也是因为这个原因，聚簇索引的插入顺序最好按照主键单调的顺序插入，否则会频繁的引起页分裂，严重影响性能。
在InnoDB中，如果只需要查找索引的列，就尽量不要加入其它的列，这样会提高查询效率。
*使用主索引的时候，更适合使用聚簇索引，因为聚簇索引只需要查找一次，而非聚簇索引在查到数据的地址后，还要进行一次I/O查找数据。
*因为聚簇辅助索引存储的是主键的键值，因此可以在数据行移动或者页分裂的时候降低成本，因为这时不用维护辅助索引。但是由于主索引存储的是数据本身，因此聚簇索引会占用更多的空间。

*聚簇索引在插入新数据的时候比非聚簇索引慢很多，因为插入新数据时需要检测主键是否重复，这需要遍历主索引的所有叶节点，而非聚簇索引的叶节点保存的是数据地址，占用空间少，因此分布集中，查询的时候I/O更少，但聚簇索引的主索引中存储的是数据本身，数据占用空间大，分布范围更大，可能占用好多的扇区，因此需要更多次I/O才能遍历完毕。

下图可以形象的说明聚簇索引和非聚簇索引的区别

从上图中可以看到聚簇索引的辅助索引的叶子节点的data存储的是主键的值，主索引的叶子节点的data存储的是数据本身，也就是说数据和索引存储在一起，并且索引查询到的地方就是数据（data）本身，那么索引的顺序和数据本身的顺序就是相同的；

而非聚簇索引的主索引和辅助索引的叶子节点的data都是存储的数据的物理地址，也就是说索引和数据并不是存储在一起的，数据的顺序和索引的顺序并没有任何关系，也就是索引顺序与数据物理排列顺序无关。

此外MyISAM和innoDB的区别总结如下：

MyISAM和innoDB引擎对比
MyISAM innoDB
索引类型 非聚簇 聚簇
支持事务 是 否
支持表锁 是 是
支持行锁 否 是（默认）
支持外键 否 是
支持全文索引 是 是（5.6以后支持）
适用操作类型 大量select下使用 大量insert、delete和update下使用
总结如下：

InnoDB 支持事务，支持行级别锁定，支持 B-tree、Full-text 等索引，不支持 Hash 索引；
MyISAM 不支持事务，支持表级别锁定，支持 B-tree、Full-text 等索引，不支持 Hash 索引；
此外，Memory 不支持事务，支持表级别锁定，支持 B-tree、Hash 等索引，不支持 Full-text 索引；

四.1.事务会出现哪些并发性问题？怎么解决?
1）丢失更新：撤消一个事务时，把其它事务已提交的更新的数据覆盖了。
2）脏读：一个事务读到另一个事务未提交的更新数据。
3）幻读：一个事务执行两次查询，但第二次查询比第一次查询多出了一些数据行。
4）不可重复读：一个事务两次读同一行数据，可是这两次读到的数据不一样。
2.事务的隔离级别
为了解决多个事务并发会引发的问题。数据库系统提供了四种事务隔离级别供用户选择。
? Serializable：串行化。隔离级别最高。
? Repeatable Read：可重复读。
? Read Committed：读已提交数据。
? Read Uncommitted：读未提交数据。隔离级别最差。
数据库系统采用不同的锁类型来实现以上四种隔离级别，具体的实现过程对用户是透明的。用户应该关心的是如何选择合适的隔离级别。
对于多数应用程序，可以优先考虑把数据库系统的隔离级别设为Read Committed，它能够避免脏读，而且具有较好的并发性能。
每个数据库连接都有一个全局变量@@tx_isolation，表示当前的事务隔离级别。JDBC数据库连接使用数据库系统默认的隔离级别。在Hibernate的配置文件中可以显示地设置隔离级别。每一种隔离级别对应着一个正整数。
? Read Uncommitted: 1
? Read Committed: 2
? Repeatable Read: 4
? Serializable: 8
在hibernate.cfg.xml中设置隔离级别如下：


2

设置之后，在开始一个事务之前，Hibernate将为从连接池中获得的JDBC连接设置级别。需要注意的是，在受管理环境中，如果Hibernate使用的数据库连接来自于应用服务器提供的数据源，Hibernate不会改变这些连接的事务隔离级别。在这种情况下，应该通过修改应用服务器的数据源配置来修改隔离级别。

3.事务并发锁：行级、表级
从字面上看，行级锁的作用范围肯定比表级锁的作用范围要小；行级锁和表级锁是根据锁的粒度来区分的，行记录，表都是资源，锁是作用在这些资源上的。如果粒度比较小(比如行级锁)，可以增加系统的并发量但需要较大的系统开销，会影响到性能，出现死锁，，因为粒度小则操作的锁的数量会增加;如果作用在表上，粒度大，开销小，维护的锁少，不会出现死锁，但是并发是相当昂贵的，因为锁定了整个表就限制了其它事务对这个表中其他记录的访问。

行级锁：(tx锁，也叫事务锁)

一、悲观锁：数据库行级锁，目的是让数据被查出来的时候就加上锁，然后再执行下面的程序逻辑，这样后面为了操作相同数据而进来的请求，就会在一开始就被拦住（这种效果千万不要以为可以做防重复提交）

在操作DML（insert，update，delete）语句时，oracle会自动加上行级锁，在select * from table for update 【of column】【nowait|wait 3】时，oracle也会自动加锁
单表 for update：

1. 一般在for update 时加nowait，这样就不用等待其他事务执行了，一判断有事务，立马抛出错误。

下面简单说一下 for update的四种情况：

1.1 select * from table where id = ‘1001’ for update 锁住了这条数据，那么另外一个人对该笔数据进行DML操作或者也执行同样的for update操作时，会检测到这笔数据上有行级锁，那么就会等待着锁释放；

这样就会出现一个问题：其他的程序如果需要对这笔数据操作，就需要等，至于等多久要看锁什么时候释放！

1.2 select * from table where id = ‘1001’ for update nowait，意思就是如果这笔数据上本身加了锁，另外一个人去执行这句SQL的时候，发现加了锁，就会直接抛出异常（ORA-00054:资源正忙），不会等待这笔数据的锁释放。

1.3 select * from table where id = ‘1001’ for update wait 5；意思就是如果这笔数据被锁住，另外一个人如果执行这句SQL后，会等待5秒，如果5秒后这句SQL还没有得到这笔数据的锁，就会抛出异常（ORA-00054:资源正忙）

1.4 我们先执行 A语句：select * from table where id = ‘1001’ for update 把1001加上锁，然后再执行 B语句：select * from table where id = ‘1001’ and id =‘1002’ for update;这时候肯定查不出来，因为A已经把B要加锁的数据锁了，这样B联1002的数据都查不出来
解决方案：skip locked

如果把B语句改为：select * from table where id = ‘1001’ and id =‘1002’ for update skip locked；意思就是执行的时候如果发现要查询的数据有锁，就把加了锁的数据排除，把剩下的数据加锁，然后查出来！

上面讲到了 for update 的四种方式，实际情况如何选择呢？

关于NOWAIT(如果一定要用FOR UPDATE，我更建议加上NOWAIT)
当有LOCK冲突时会提示错误并结束STATEMENT而不是在那里等待(比如:要查的行已经被其它事务锁了,当前的锁事务与之冲突,加上nowait,当前的事务会结束会提示错误并立即结束 STATEMENT而不再等待).
WAIT 子句指定等待其他用户释放锁的秒数，防止无限期的等待。
　　“使用FOR UPDATE WAIT”子句的优点如下：
　　1.防止无限期地等待被锁定的行；
　　2.允许应用程序中对锁的等待时间进行更多的控制。
　　3.对于交互式应用程序非常有用，因为这些用户不能等待不确定

4.若使用了skip locked，则可以越过锁定的行，不会报告由wait n 引发的‘资源忙’异常报告

关联表for update：

2. 现在大部分业务都是联表查询，如果用for update 的话，就会把所有关联表查询出来的列所在的行全部加锁，那这个锁可就重了，比如：

select * from t1,t2 where t1.id = t2.id and t1.age = ‘20’ for update；就会把T1和T2两个表中符合条件的行锁定；

如果上述SQL我只想对T1表的结果集加锁，怎么办？答案：of column_name

例子：

select * from t1,t2 where t1.id = t2.id and t1.age = ‘20’ for update of t1.id;

这样就会只把T1表中的符合条件的行加锁，T2表中符合条件的行不会加锁。

PS:如果单表for update of column_name查询，其实和 for update操作是一样的！

二、乐观锁：这不是数据库本身的锁，是利用数据比较结果来当做抽象的锁；举个例子就明白：
说明：小明成绩错了，要改成绩。班主任能改，年级主任也能改！

程序：

					{
					
					//先查出来小明的成绩
					
					select t.id,t.result from  T t where t.id='10001';---10001,59
					
					//更新成绩,改为60
					
					update T t set t.result =‘60’ where t.id='10001'
					
					and t.result = '59'  //加上这个条件的目的就是为了验证，数据库里10001的成绩在此期间有没有被其他人改过，如果改过，那就更新条数为0（因为找不到符合条件的数据）；
					
					PS:没有找到数据，所以没更新10001这笔数据，最好是程序返回一个没有更新到这笔数据的提示，如果不加任何提示，前端就会认为更新成功了！
					
					}
					
					分析：
					
					1.利用数据库中的数据和已经取出的数据的一致性做为“锁”，与for update相比，乐观锁机制是等到更改数据的时候才去校验，悲观锁是读取数据就开始做了校验，从这个角度来看，乐观锁是对数据库没有额外开销，那么效率相对是高的。

2. 需要更改的字段可以作为乐观锁的验证字段；或者表里建立version版本号，每更新一次数据版本号+1；或者加lastupdatedate（最后更新时间），同理：数据更改的同时lastupdatedate也跟着变更！

3.其实乐观锁存在一个很致命的问题：

场景： 已上述小明改成绩为例，假设班主任改的同时，年级主任也改，两个请求几乎同时执行了查询：

select t.id,t.result from T t where t.id=‘10001’;—10001,59

都查出来是59分！！

然后几乎同时执行了改成绩，班主任改成60分，年级主任改成了80分，关键是还都update到10001了

班主任：update T t set t.result =‘60’ where t.id=‘10001’

and t.result = ‘59’ ；

年级主任：

update T t set t.result =‘80’ where t.id=‘10001’

and t.result = ‘59’ ；

这时候班主任事务先提交，数据库小明成绩改成了60，年级主任事务紧接着提交，小明的成绩又从60改成了80，那么对于班主任来说，他的数据就是更新丢失！！！所以大家使用起来要注意并发的情况！！

表级锁：

一般指的是表结构共享锁。是不可对该表进行DDL操作，但是对于该表数据的DML操作不受影响