MySQL面试题及答案整理,史上最全!
MySQL⾯试题及答案整理，史上最全！
原⽂链接：
前⾔
本⽂主要受众为开发⼈员，所以不涉及到MySQL的服务部署等操作，且内容较多,⼤家准备好耐⼼和⽠⼦矿泉⽔.
前⼀阵系统的学习了⼀下MySQL，也有⼀些实际操作经验，偶然看到⼀篇和MySQL相关的⾯试⽂章，发现其中的⼀些问题⾃⼰也回答不好，虽然知识点⼤部分都知道，但是⽆法将知识串联起来.
因此决定搞⼀个MySQL灵魂100问，试着⽤回答问题的⽅式，让⾃⼰对知识点的理解更加深⼊⼀点.
此⽂不会事⽆巨细的从select的⽤法开始讲解mysql，主要针对的是开发⼈员需要知道的⼀些MySQL的知识点，主要包括索引，事务，优化等⽅⾯，以在⾯试中⾼频的问句形式给出答案.
索引相关
关于MySQL的索引，曾经进⾏过⼀次总结,⽂章链接在这⾥ Mysql索引原理及其优化.
1. 什么是索引?
索引是⼀种数据结构，可以帮助我们快速的进⾏数据的查.
2. 索引是个什么样的数据结构呢?
索引的数据结构和具体存储引擎的实现有关, 在MySQL中使⽤较多的索引有Hash索引,B+树索引等,⽽我们经常使⽤的InnoDB存储引擎的默认索引实现为:B+树索引.
3. Hash索引和B+树所有有什么区别或者说优劣呢?
⾸先要知道Hash索引和B+树索引的底层实现原理:
hash索引底层就是hash表，进⾏查时，调⽤⼀次hash函数就可以获取到相应的键值，之后进⾏回表查询获得实际数据.B+树底层实现是多路平衡查树.对于每⼀次的查询都是从根节点出发，查到叶⼦节点⽅可以获得所查键值，然后根据查询判断是否需要回表查询数据.
那么可以看出他们有以下的不同:
hash索引进⾏等值查询更快(⼀般情况下)，但是却⽆法进⾏范围查询.
因为在hash索引中经过hash函数建⽴索引之后，索引的顺序与原顺序⽆法保持⼀致，不能⽀持范围查询.⽽B+树的的所有节点皆遵循(左节点⼩于⽗节点，右节点⼤于⽗节点，多叉树也类似)，天然⽀持范围.
hash索引不⽀持使⽤索引进⾏排序，原理同上.
hash索引不⽀持模糊查询以及多列索引的最左前缀匹配.原理也是因为hash函数的不可预测.AAAA和AAAAB的索引没有相关性.
hash索引任何时候都避免不了回表查询数据,⽽B+树在符合某些条件(聚簇索引，覆盖索引等)的时候可以只通过索引完成查询.
hash索引虽然在等值查询上较快，但是不稳定.性能不可预测，当某个键值存在⼤量重复的时候，发⽣hash碰撞，此时效率可能极差.⽽B+树的查询效率⽐较稳定，对于所有的查询都是从根节点到叶⼦节点，且树的⾼度较低.
因此，在⼤多数情况下，直接选择B+树索引可以获得稳定且较好的查询速度.⽽不需要使⽤hash索引.
4. 上⾯提到了B+树在满⾜聚簇索引和覆盖索引的时候不需要回表查询数据，什么是聚簇索引?
在B+树的索引中，叶⼦节点可能存储了当前的key值，也可能存储了当前的key值以及整⾏的数据，这就是聚簇索引和⾮聚簇索引. 在InnoDB中，只有主键索引是聚簇索引，如果没有主键，则挑选⼀个唯⼀键建⽴聚簇索引.如果没有唯⼀键，则隐式的⽣成⼀个键来建⽴聚簇索引.
当查询使⽤聚簇索引时，在对应的叶⼦节点，可以获取到整⾏数据，因此不⽤再次进⾏回表查询.
5. ⾮聚簇索引⼀定会回表查询吗?
不⼀定，这涉及到查询语句所要求的字段是否全部命中了索引，如果全部命中了索引，那么就不必再进⾏回表查询.
举个简单的例⼦，假设我们在员⼯表的年龄上建⽴了索引，那么当进⾏select age from employee where age < 20的查询时，在索引的叶⼦节点上，已经包含了age信息，不会再次进⾏回表查询.
6. 在建⽴索引的时候，都有哪些需要考虑的因素呢?
建⽴索引的时候⼀般要考虑到字段的使⽤频率，经常作为条件进⾏查询的字段⽐较适合.如果需要建⽴联合索引的话，还需要考虑联合索引中的顺序.此外也要考虑其他⽅⾯,⽐如防⽌过多的所有对表造成太⼤的压⼒.这些都和实际的表结构以及查询⽅式有关.
7. 联合索引是什么?为什么需要注意联合索引中的顺序?
MySQL可以使⽤多个字段同时建⽴⼀个索引，叫做联合索引.在联合索引中，如果想要命中索引，需要按照建⽴索引时的字段顺序挨个使⽤，否则⽆法命中索引.
具体原因为:
MySQL使⽤索引时需要索引有序，假设现在建⽴了"name,age,school"的联合索引，那么索引的排序为: 先按照name排序，如果name相同，则按照age排序，如果age的值也相等，则按照school进⾏排序.
当进⾏查询时，此时索引仅仅按照name严格有序，因此必须⾸先使⽤name字段进⾏等值查询，之后对于匹配到的列⽽⾔，其按照age字段严格有序，此时可以使⽤age字段⽤做索引查,,，以此类推.因此在建⽴联合索引的时候应该注意索引列的顺序,⼀般情况下，将查询需求频繁或者字段选择性⾼的列放在前⾯.此外可以根据特例的查询或者表结构进⾏单独的调整.
8. 创建的索引有没有被使⽤到?或者说怎么才可以知道这条语句运⾏很慢的原因?
MySQL提供了explain命令来查看语句的执⾏计划,MySQL在执⾏某个语句之前，会将该语句过⼀遍查询优化器，之后会拿到对语句的分析，也就是执⾏计划，其中包含了许多信息. 可以通过其中和索引有关的信息来分析是否命中了索引，例如possilbe_key,key,key_len等字段，分别说明了此语句可能会使⽤的索引，实际使⽤的索引以及使⽤的索引长度.
9. 那么在哪些情况下会发⽣针对该列创建了索引但是在查询的时候并没有使⽤呢?
使⽤不等于查询,
列参与了数学运算或者函数
在字符串like时左边是通配符.类似于'%aaa'.
当mysql分析全表扫描⽐使⽤索引快的时候不使⽤索引.
当使⽤联合索引，前⾯⼀个条件为范围查询，后⾯的即使符合最左前缀原则，也⽆法使⽤索引.
以上情况,MySQL⽆法使⽤索引.
事务相关
1. 什么是事务?
理解什么是事务最经典的就是转账的栗⼦，相信⼤家也都了解，这⾥就不再说⼀边了.
事务是⼀系列的操作，他们要符合ACID特性.最常见的理解就是：事务中的操作要么全部成功，要么全部失败.但是只是这样还不够的.
2. ACID是什么?可以详细说⼀下吗?
A=Atomicity
原⼦性，就是上⾯说的，要么全部成功，要么全部失败.不可能只执⾏⼀部分操作.
C=Consistency
系统(数据库)总是从⼀个⼀致性的状态转移到另⼀个⼀致性的状态，不会存在中间状态.
I=Isolation
隔离性: 通常来说:⼀个事务在完全提交之前，对其他事务是不可见的.注意前⾯的通常来说加了红⾊，意味着有例外情况.
D=Durability
持久性,⼀旦事务提交，那么就永远是这样⼦了，哪怕系统崩溃也不会影响到这个事务的结果.
3. 同时有多个事务在进⾏会怎么样呢?
多事务的并发进⾏⼀般会造成以下⼏个问题:
脏读: A事务读取到了B事务未提交的内容,⽽B事务后⾯进⾏了回滚.
不可重复读: 当设置A事务只能读取B事务已经提交的部分，会造成在A事务内的两次查询，结果竟然不⼀样，因为在此期间B事务进⾏了提交操作.
幻读: A事务读取了⼀个范围的内容,⽽同时B事务在此期间插⼊了⼀条数据.造成"幻觉".
4. 怎么解决这些问题呢?MySQL的事务隔离级别了解吗?
MySQL的四种隔离级别如下:
未提交读(READ UNCOMMITTED)
这就是上⾯所说的例外情况了，这个隔离级别下，其他事务可以看到本事务没有提交的部分修改.因此会造成脏读的问题(读取到了其他事务未提交的部分,⽽之后该事务进⾏了回滚).
这个级别的性能没有⾜够⼤的优势，但是⼜有很多的问题，因此很少使⽤.
已提交读(READ COMMITTED)
其他事务只能读取到本事务已经提交的部分.这个隔离级别有不可重复读的问题，在同⼀个事务内的两次
读取，拿到的结果竟然不⼀样，因为另外⼀个事务对数据进⾏了修改.
REPEATABLE READ(可重复读)
可重复读隔离级别解决了上⾯不可重复读的问题(看名字也知道)，但是仍然有⼀个新问题，就是幻读，当你读取id> 10 的数据⾏时，对涉及到的所有⾏加上了读锁，此时例外⼀个事务新插⼊了⼀条id=11的数据，因为是新插⼊的，所以不会触发上⾯的锁的排斥，那么进⾏本事务进⾏下⼀次的查询时会发现有⼀条id=11的数据,⽽上次的查询操作并没有获取到，再进⾏插⼊就会有主键冲突的问题.
SERIALIZABLE(可串⾏化)
这是最⾼的隔离级别，可以解决上⾯提到的所有问题，因为他强制将所以的操作串⾏执⾏，这会导致并发性能极速下降，因此也不是很常⽤.
5. Innodb使⽤的是哪种隔离级别呢?
InnoDB默认使⽤的是可重复读隔离级别.
6. 对MySQL的锁了解吗?
当数据库有并发事务的时候，可能会产⽣数据的不⼀致，这时候需要⼀些机制来保证访问的次序，锁机制就是这样的⼀个机制.
就像酒店的房间，如果⼤家随意进出，就会出现多⼈抢夺同⼀个房间的情况,⽽在房间上装上锁，申请到钥匙的⼈才可以⼊住并且将房间锁起来，其他⼈只有等他使⽤完毕才可以再次使⽤.
7. MySQL都有哪些锁呢?像上⾯那样⼦进⾏锁定岂不是有点阻碍并发效率了?
从锁的类别上来讲，有共享锁和排他锁.
共享锁: ⼜叫做读锁. 当⽤户要进⾏数据的读取时，对数据加上共享锁.共享锁可以同时加上多个.
排他锁: ⼜叫做写锁. 当⽤户要进⾏数据的写⼊时，对数据加上排他锁.排他锁只可以加⼀个，他和其他的排他锁，共享锁都相斥.
⽤上⾯的例⼦来说就是⽤户的⾏为有两种,⼀种是来看房，多个⽤户⼀起看房是可以接受的. ⼀种是真正的⼊住⼀晚，在这期间,⽆论是想⼊住的还是想看房的都不可以.
锁的粒度取决于具体的存储引擎,InnoDB实现了⾏级锁，页级锁，表级锁.
他们的加锁开销从⼤⼤⼩，并发能⼒也是从⼤到⼩.
表结构设计
1. 为什么要尽量设定⼀个主键?
主键是数据库确保数据⾏在整张表唯⼀性的保障，即使业务上本张表没有主键，也建议添加⼀个⾃增长的ID列作为主键.设定了主键之后，在后续的删改查的时候可能更加快速以及确保操作数据范围安全.
2. 主键使⽤⾃增ID还是UUID?
推荐使⽤⾃增ID，不要使⽤UUID.
因为在InnoDB存储引擎中，主键索引是作为聚簇索引存在的，也就是说，主键索引的B+树叶⼦节点上存储了主键索引以及全部的数据(按照顺序)，如果主键索引是⾃增ID，那么只需要不断向后排列即可，如果是UUID，由于到来的ID与原来的⼤⼩不确定，会造成⾮常多的数据插⼊，数据移动，然后导致产⽣很多的内存碎⽚，进⽽造成插⼊性能的下降.
总之，在数据量⼤⼀些的情况下,⽤⾃增主键性能会好⼀些.
图⽚来源于《⾼性能MySQL》: 其中默认后缀为使⽤⾃增ID,_uuid为使⽤UUID为主键的测试，测试了插⼊100w⾏和300w⾏的性能.
关于主键是聚簇索引，如果没有主键,InnoDB会选择⼀个唯⼀键来作为聚簇索引，如果没有唯⼀键，会⽣成⼀个隐式的主键.
If you define a PRIMARY KEY on your table, InnoDB uses it as the clustered index.
If you do not define a PRIMARY KEY for your table, MySQL picks the first UNIQUE index that has only NOT NULL columns as the primary key and InnoDB uses it as the clustered index.
3. 字段为什么要求定义为not null?
MySQL官⽹这样介绍:
NULL columns require additional space in the rowto record whether their values are NULL. For MyISAM tables, each NULL
columntakes one bit extra, rounded up to the nearest byte.
null值会占⽤更多的字节，且会在程序中造成很多与预期不符的情况.
4. 如果要存储⽤户的密码散列，应该使⽤什么字段进⾏存储?
密码散列，盐,⽤户⾝份证号等固定长度的字符串应该使⽤char⽽不是varchar来存储，这样可以节省空间且提⾼检索效率.
存储引擎相关
1. MySQL⽀持哪些存储引擎?
MySQL⽀持多种存储引擎,⽐如InnoDB,MyISAM,Memory,Archive等等.在⼤多数的情况下，直接选择使⽤InnoDB引擎都是最合适的,InnoDB也是MySQL的默认存储引擎.
1. InnoDB和MyISAM有什么区别?
InnoDB⽀持事物，⽽MyISAM不⽀持事物
InnoDB⽀持⾏级锁，⽽MyISAM⽀持表级锁
InnoDB⽀持MVCC, ⽽MyISAM不⽀持
InnoDB⽀持外键，⽽MyISAM不⽀持
InnoDB不⽀持全⽂索引，⽽MyISAM⽀持。
零散问题
1. MySQL中的varchar和char有什么区别.
char是⼀个定长字段，假如申请了char(10)的空间，那么⽆论实际存储多少内容.该字段都占⽤10个字符,⽽varchar是变长的，也就是说申请的只是最⼤长度，占⽤的空间为实际字符长度+1，最后⼀个字符存储使⽤了多长的空间.
在检索效率上来讲,char > varchar，因此在使⽤中，如果确定某个字段的值的长度，可以使⽤char，否则应该尽量使⽤varchar.例如存储⽤户MD5加密后的密码，则应该使⽤char.
2. varchar(10)和int(10)代表什么含义?
varchar的10代表了申请的空间长度，也是可以存储的数据的最⼤长度,⽽int的10只是代表了展⽰的长度，不⾜10位以0填充.也就是说,int(1)和int(10)所能存储的数字⼤⼩以及占⽤的空间都是相同的，只是在展⽰时按照长度展⽰.
3. MySQL的binlog有有⼏种录⼊格式?分别有什么区别?
有三种格式,statement,row和mixed.
statement模式下，记录单元为语句.即每⼀个sql造成的影响会记录.由于sql的执⾏是有上下⽂的，因此在保存的时候需要保存相关的信息，同时还有⼀些使⽤了函数之类的语句⽆法被记录复制.
row级别下，记录单元为每⼀⾏的改动，基本是可以全部记下来但是由于很多操作，会导致⼤量⾏的改动(⽐如alter table)，因此这种模式的⽂件保存的信息太多,⽇志量太⼤.
mixed. ⼀种折中的⽅案，普通操作使⽤statement记录，当⽆法使⽤statement的时候使⽤row.
怎么申请博客此外，新版的MySQL中对row级别也做了⼀些优化，当表结构发⽣变化的时候，会记录语句⽽不是逐⾏记录.
4. 超⼤分页怎么处理?
超⼤的分页⼀般从两个⽅向上来解决.
数据库层⾯，这也是我们主要集中关注的(虽然收效没那么⼤)，类似于select * from table where age > 20 limit 1000000,10这种查询其实也是有可以优化的余地的. 这条语句需要load1000000数据然后基本上全部丢弃，只取10条当然⽐较慢. 当时我们可以修改为select * from table where id in (select id from table where age > 20 limit 1000000,10).这样虽然也load了⼀百万的数据，但是由于索引覆盖，要查询的所有字段都在索引中,
所以速度会很快. 同时如果ID连续的好，我们还可以select * from table where id > 1000000 limit 10，效率也是不错的，优化的可能性有许多种，但是核⼼思想都⼀样，就是减少load的数据.
从需求的⾓度减少这种请求….主要是不做类似的需求(直接跳转到⼏百万页之后的具体某⼀页.只允许逐页查看或者按照给定的路线⾛，这样可预测，可缓存)以及防⽌ID泄漏且连续被⼈恶意攻击.
解决超⼤分页，其实主要是靠缓存，可预测性的提前查到内容，缓存⾄redis等k-V数据库中，直接返回即可.
在阿⾥巴巴《Java开发⼿册》中，对超⼤分页的解决办法是类似于上⾯提到的第⼀种.
5. 关⼼过业务系统⾥⾯的sql耗时吗?统计过慢查询吗?对慢查询都怎么优化过?
在业务系统中，除了使⽤主键进⾏的查询，其他的我都会在测试库上测试其耗时，慢查询的统计主要由运维在做，会定期将业务中的慢查询反馈给我们.
慢查询的优化⾸先要搞明⽩慢的原因是什么? 是查询条件没有命中索引?是load了不需要的数据列?还是数据量太⼤?
所以优化也是针对这三个⽅向来的,
⾸先分析语句，看看是否load了额外的数据，可能是查询了多余的⾏并且抛弃掉了，可能是加载了许多结果中并不需要的列，对语句进⾏分析以及重写.
分析语句的执⾏计划，然后获得其使⽤索引的情况，之后修改语句或者修改索引，使得语句可以尽可能的命中索引.
如果对语句的优化已经⽆法进⾏，可以考虑表中的数据量是否太⼤，如果是的话可以进⾏横向或者纵向的分表.
6. 上⾯提到横向分表和纵向分表，可以分别举⼀个适合他们的例⼦吗?
横向分表是按⾏分表.假设我们有⼀张⽤户表，主键是⾃增ID且同时是⽤户的ID.数据量较⼤，有1亿多条，
那么此时放在⼀张表⾥的查询效果就不太理想.我们可以根据主键ID进⾏分表,⽆论是按尾号分，或者按ID的区间分都是可以的. 假设按照尾号0-99分为100个表，那么每张表中的数据就仅有100w.这时的查询效率⽆疑是可以满⾜要求的.
纵向分表是按列分表.假设我们现在有⼀张⽂章表.包含字段id-摘要-内容.⽽系统中的展⽰形式是刷新出⼀个列表，列表中仅包含标题和摘要，当⽤户点击某篇⽂章进⼊详情时才需要正⽂内容.此时，如果数据量⼤，将内容这个很⼤且不经常使⽤的列放在⼀起会拖慢原表的查询速度.我们可以将上⾯的表分为两张.id-摘要,id-内容.当⽤户点击详情，那主键再来取⼀次内容即可.⽽增加的存储量只是很⼩的主键字段.代价很⼩.
当然，分表其实和业务的关联度很⾼，在分表之前⼀定要做好调研以及benchmark.不要按照⾃⼰的猜想盲⽬操作.
7. 什么是存储过程？有哪些优缺点？
存储过程是⼀些预编译的SQL语句。1、更加直⽩的理解：存储过程可以说是⼀个记录集，它是由⼀些T-SQL语句组成的代码块，这些T-SQL语句代码像⼀个⽅法⼀样实现⼀些功能（对单表或多表的增删改查），然后再给这个代码块取⼀个名字，在⽤到这个功能的时候调⽤他就⾏了。2、存储过程是⼀个预编译的代码块，执⾏效率⽐较⾼,⼀个存储过程替代⼤量T_SQL语句，可以降低⽹络通信量，提⾼通信速
率，可以⼀定程度上确保数据安全
但是，在互联⽹项⽬中，其实是不太推荐存储过程的,⽐较出名的就是阿⾥的《Java开发⼿册》中禁⽌使⽤存储过程，我个⼈的理解是，在互联⽹

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。