MySQL 数据库经典面试题解析.docx
《MySQL 数据库经典面试题解析.docx》由会员分享，可在线阅读，更多相关《MySQL 数据库经典面试题解析.docx（68页珍藏版）》请在冰点文库上搜索。
MySQL数据库经典面试题解析
100道MySQL数据库经典面试题
详细解析
数据库
1.MySQL索引使用有哪些注意事项呢？
可以从三个维度回答这个问题：
索引哪些情况会失效，索引不适合哪些场景，索引规则
索引哪些情况会失效
▪
查询条件包含or，可能导致索引失效
▪
▪
如何字段类型是字符串，where时一定用引号括起来，否则索引失效
▪
▪
like通配符可能导致索引失效。
▪
▪
联合索引，查询时的条件列不是联合索引中的第一个列，索引失效。
▪
▪
在索引列上使用mysql的内置函数，索引失效。
▪
▪
对索引列运算（如，+、-、*、/），索引失效。
▪
▪
索引字段上使用（！
=或者<>，notin）时，可能会导致索引失效。
▪
▪
索引字段上使用isnull，isnotnull，可能导致索引失效。
▪
▪
左连接查询或者右连接查询查询关联的字段编码格式不一样，可能导致索引失效。
▪
▪
mysql估计使用全表扫描要比使用索引快,则不使用索引。
▪
索引不适合哪些场景
▪
数据量少的不适合加索引
▪
▪
更新比较频繁的也不适合加索引
▪
▪
区分度低的字段不适合加索引（如性别）
▪
索引的一些潜规则
▪
覆盖索引
▪
▪
回表
▪
▪
索引数据结构（B+树）
▪
▪
最左前缀原则
▪
▪
索引下推
▪
2.MySQL遇到过死锁问题吗，你是如何解决的？
我排查死锁的一般步骤是酱紫的：
▪
查看死锁日志showengineinnodbstatus;
▪
▪
找出死锁Sql
▪
▪
分析sql加锁情况
▪
▪
模拟死锁案发
▪
▪
分析死锁日志
▪
▪
分析死锁结果
▪
3.日常工作中你是怎么优化SQL的？
可以从这几个维度回答这个问题：
▪
加索引
▪
▪
避免返回不必要的数据
▪
▪
适当分批量进行
▪
▪
优化sql结构
▪
▪
分库分表
▪
▪
读写分离
▪
4.说说分库与分表的设计
分库分表方案，分库分表中间件，分库分表可能遇到的问题
分库分表方案:
▪
水平分库：
以字段为依据，按照一定策略（hash、range等），将一个库中的数据拆分到多个库中。
▪
▪
水平分表：
以字段为依据，按照一定策略（hash、range等），将一个表中的数据拆分到多个表中。
▪
▪
垂直分库：
以表为依据，按照业务归属不同，将不同的表拆分到不同的库中。
▪
▪
垂直分表：
以字段为依据，按照字段的活跃性，将表中字段拆到不同的表（主表和扩展表）中。
▪
常用的分库分表中间件：
▪
sharding-jdbc（当当）
▪
▪
Mycat
▪
▪
TDDL（淘宝）
▪
▪
Oceanus（58同城数据库中间件）
▪
▪
vitess（谷歌开发的数据库中间件）
▪
▪
Atlas（Qihoo360）
▪
分库分表可能遇到的问题
▪
事务问题：
需要用分布式事务啦
▪
▪
跨节点Join的问题：
解决这一问题可以分两次查询实现
▪
▪
跨节点的count,orderby,groupby以及聚合函数问题：
分别在各个节点上得到结果后在应用程序端进行合并。
▪
▪
数据迁移，容量规划，扩容等问题
▪
▪
ID问题：
数据库被切分后，不能再依赖数据库自身的主键生成机制啦，最简单可以考虑UUID
▪
▪
跨分片的排序分页问题（后台加大pagesize处理？
）
▪
5.InnoDB与MyISAM的区别
▪
InnoDB支持事务，MyISAM不支持事务
▪
▪
InnoDB支持外键，MyISAM不支持外键
▪
▪
InnoDB支持MVCC（多版本并发控制），MyISAM不支持
▪
▪
selectcount（*）fromtable时，MyISAM更快，因为它有一个变量保存了整个表的总行数，可以直接读取，InnoDB就需要全表扫描。
▪
▪
Innodb不支持全文索引，而MyISAM支持全文索引（5.7以后的InnoDB也支持全文索引）
▪
▪
InnoDB支持表、行级锁，而MyISAM支持表级锁。
▪
▪
InnoDB表必须有主键，而MyISAM可以没有主键
▪
▪
Innodb表需要更多的内存和存储，而MyISAM可被压缩，存储空间较小，。
▪
▪
Innodb按主键大小有序插入，MyISAM记录插入顺序是，按记录插入顺序保存。
▪
▪
InnoDB存储引擎提供了具有提交、回滚、崩溃恢复能力的事务安全，与MyISAM比InnoDB写的效率差一些，并且会占用更多的磁盘空间以保留数据和索引
▪
6.数据库索引的原理，为什么要用B+树，为什么不用二叉树？
可以从几个维度去看这个问题，查询是否够快，效率是否稳定，存储数据多少，以及查找磁盘次数，为什么不是二叉树，为什么不是平衡二叉树，为什么不是B树，而偏偏是B+树呢？
为什么不是一般二叉树？
如果二叉树特殊化为一个链表，相当于全表扫描。
平衡二叉树相比于二叉查找树来说，查找效率更稳定，总体的查找速度也更快。
为什么不是平衡二叉树呢？
我们知道，在内存比在磁盘的数据，查询效率快得多。
如果树这种数据结构作为索引，那我们每查找一次数据就需要从磁盘中读取一个节点，也就是我们说的一个磁盘块，但是平衡二叉树可是每个节点只存储一个键值和数据的，如果是B树，可以存储更多的节点数据，树的高度也会降低，因此读取磁盘的次数就降下来啦，查询效率就快啦。
那为什么不是B树而是B+树呢？
1）B+树非叶子节点上是不存储数据的，仅存储键值，而B树节点中不仅存储键值，也会存储数据。
innodb中页的默认大小是16KB，如果不存储数据，那么就会存储更多的键值，相应的树的阶数（节点的子节点树）就会更大，树就会更矮更胖，如此一来我们查找数据进行磁盘的IO次数有会再次减少，数据查询的效率也会更快。
2）B+树索引的所有数据均存储在叶子节点，而且数据是按照顺序排列的，链表连着的。
那么B+树使得范围查找，排序查找，分组查找以及去重查找变得异常简单。
7.聚集索引与非聚集索引的区别
▪
一个表中只能拥有一个聚集索引，而非聚集索引一个表可以存在多个。
▪
▪
聚集索引，索引中键值的逻辑顺序决定了表中相应行的物理顺序；非聚集索引，索引中索引的逻辑顺序与磁盘上行的物理存储顺序不同。
▪
▪
索引是通过二叉树的数据结构来描述的，我们可以这么理解聚簇索引：
索引的叶节点就是数据节点。
而非聚簇索引的叶节点仍然是索引节点，只不过有一个指针指向对应的数据块。
▪
▪
聚集索引：
物理存储按照索引排序；非聚集索引：
物理存储不按照索引排序；
▪
何时使用聚集索引或非聚集索引？
8.limit1000000加载很慢的话，你是怎么解决的呢？
方案一：
如果id是连续的，可以这样，返回上次查询的最大记录（偏移量），再往下limit
1.
selectid，namefromemployeewhereid>1000000limit10.
2.
方案二：
在业务允许的情况下限制页数：
建议跟业务讨论，有没有必要查这么后的分页啦。
因为绝大多数用户都不会往后翻太多页。
方案三：
orderby+索引（id为索引）
1.
selectid，namefromemployeeorderbyidlimit1000000，10
2.
方案四：
利用延迟关联或者子查询优化超多分页场景。
（先快速定位需要获取的id段，然后再关联）
1.
SELECTa.*FROMemployeea,（selectidfromemployeewhere条件LIMIT1000000,10）bwherea.id=b.id
2.
9.如何选择合适的分布式主键方案呢？
▪
数据库自增长序列或字段。
▪
▪
UUID。
▪
▪
Redis生成ID
▪
▪
Twitter的snowflake算法
▪
▪
利用zookeeper生成唯一ID
▪
▪
MongoDB的ObjectId
▪
10.事务的隔离级别有哪些？
MySQL的默认隔离级别是什么？
▪
读未提交（ReadUncommitted）
▪
▪
读已提交（ReadCommitted）
▪
▪
可重复读（RepeatableRead）
▪
▪
串行化（Serializable）
▪
Mysql默认的事务隔离级别是可重复读（RepeatableRead）
11.什么是幻读，脏读，不可重复读呢？
▪
事务A、B交替执行，事务A被事务B干扰到了，因为事务A读取到事务B未提交的数据,这就是脏读
▪
▪
在一个事务范围内，两个相同的查询，读取同一条记录，却返回了不同的数据，这就是不可重复读。
▪
▪
事务A查询一个范围的结果集，另一个并发事务B往这个范围中插入/删除了数据，并静悄悄地提交，然后事务A再次查询相同的范围，两次读取得到的结果集不一样了，这就是幻读。
▪
12.在高并发情况下，如何做到安全的修改同一行数据？
要安全的修改同一行数据，就要保证一个线程在修改时其它线程无法更新这行记录。
一般有悲观锁和乐观锁两种方案~
使用悲观锁
悲观锁思想就是，当前线程要进来修改数据时，别的线程都得拒之门外~比如，可以使用select…forupdate~
1.
select*fromUserwherename=‘jay’forupdate
2.
以上这条sql语句会锁定了User表中所有符合检索条件（name=‘jay’）的记录。
本次事务提交之前，别的线程都无法修改这些记录。
使用乐观锁
乐观锁思想就是，有线程过来，先放过去修改，如果看到别的线程没修改过，就可以修改成功，如果别的线程修改过，就修改失败或者重试。
实现方式：
乐观锁一般会使用版本号机制或CAS算法实现。
13.数据库的乐观锁和悲观锁。
悲观锁：
悲观锁她专一且缺乏安全感了，她的心只属于当前事务，每时每刻都担心着它心爱的数据可能被别的事务修改，所以一个事务拥有（获得）悲观锁后，其他任何事务都不能对数据进行修改啦，只能等待锁被释放才可以执行。
乐观锁：
乐观锁的“乐观情绪”体现在，它认为数据的变动不会太频繁。
因此，它允许多个事务同时对数据进行变动。
实现方式：
乐观锁一般会使用版本号机制或CAS算法实现。
14.SQL优化的一般步骤是什么，怎么看执行计划（explain），如何理解其中各个字段的含义。
▪
showstatus命令了解各种sql的执行频率
▪
▪
通过慢查询日志定位那些执行效率较低的sql语句
▪
▪
explain分析低效sql的执行计划（这点非常重要，日常开发中用它分析Sql，会大大降低Sql导致的线上事故）
▪
15.selectforupdate有什么含义，会锁表还是锁行还是其他。
selectforupdate含义
select查询语句是不会加锁的，但是selectforupdate除了有查询的作用外，还会加锁呢，而且它是悲观锁哦。
至于加了是行锁还是表锁，这就要看是不是用了索引/主键啦。
没用索引/主键的话就是表锁，否则就是是行锁。
selectforupdate加锁验证
表结构：
1.
//id为主键，name为唯一索引
2.
3.
CREATETABLE`account`（
4.
5.
`id`int（11）NOTNULLAUTO_INCREMENT,
6.
7.
`name`varchar（255）DEFAULTNULL,
8.
9.
`balance`int（11）DEFAULTNULL,
10.
11.
PRIMARYKEY（`id`）,
12.
13.
KEY`idx_name`（`name`）USINGBTREE
14.
15.
）ENGINE=InnoDBAUTO_INCREMENT=1570068DEFAULTCHARSET=utf8
16.
id为主键，selectforupdate1270070这条记录时，再开一个事务对该记录更新，发现更新阻塞啦，其实是加锁了。
如下图：
我们再开一个事务对另外一条记录1270071更新，发现更新成功，因此，如果查询条件用了索引/主键，会加行锁~
我们继续一路向北吧，换普通字段balance吧，发现又阻塞了。
因此，没用索引/主键的话，selectforupdate加的就是表锁
16.MySQL事务得四大特性以及实现原理
▪
原子性：
事务作为一个整体被执行，包含在其中的对数据库的操作要么全部被执行，要么都不执行。
▪
▪
一致性：
指在事务开始之前和事务结束以后，数据不会被破坏，假如A账户给B账户转10块钱，不管成功与否，A和B的总金额是不变的。
▪
▪
隔离性：
多个事务并发访问时，事务之间是相互隔离的，即一个事务不影响其它事务运行效果。
简言之，就是事务之间是进水不犯河水的。
▪
▪
持久性：
表示事务完成以后，该事务对数据库所作的操作更改，将持久地保存在数据库之中。
▪
事务ACID特性的实现思想
▪
原子性：
是使用undolog来实现的，如果事务执行过程中出错或者用户执行了rollback，系统通过undolog日志返回事务开始的状态。
▪
▪
持久性：
使用redolog来实现，只要redolog日志持久化了，当系统崩溃，即可通过redolog把数据恢复。
▪
▪
隔离性：
通过锁以及MVCC,使事务相互隔离开。
▪
▪
一致性：
通过回滚、恢复，以及并发情况下的隔离性，从而实现一致性。
▪
17.如果某个表有近千万数据，CRUD比较慢，如何优化。
分库分表
某个表有近千万数据，可以考虑优化表结构，分表（水平分表，垂直分表），当然，你这样回答，需要准备好面试官问你的分库分表相关问题呀，如
▪
分表方案（水平分表，垂直分表，切分规则hash等）
▪
▪
分库分表中间件（Mycat，sharding-jdbc等）
▪
▪
分库分表一些问题（事务问题？
跨节点Join的问题）
▪
▪
解决方案（分布式事务等）
▪
索引优化
除了分库分表，优化表结构，当然还有所以索引优化等方案~
18.如何写sql能够有效的使用到复合索引。
复合索引，也叫组合索引，用户可以在多个列上建立索引,这种索引叫做复合索引。
当我们创建一个组合索引的时候，如（k1,k2,k3），相当于创建了（k1）、（k1,k2）和（k1,k2,k3）三个索引，这就是最左匹配原则。
1.
select*fromtablewherek1=AANDk2=BANDk3=D
2.
有关于复合索引，我们需要关注查询Sql条件的顺序，确保最左匹配原则有效，同时可以删除不必要的冗余索引。
19.mysql中in和exists的区别。
这个，跟一下demo来看更刺激吧，啊哈哈
假设表A表示某企业的员工表，表B表示部门表，查询所有部门的所有员工，很容易有以下SQL:
1.
select*fromAwheredeptIdin（selectdeptIdfromB）;
2.
这样写等价于：
先查询部门表B
selectdeptIdfromB
再由部门deptId，查询A的员工
select*fromAwhereA.deptId=B.deptId
可以抽象成这样的一个循环：
1.
List<>resultSet;
2.
3.
for（inti=0;i4.
5.
for（intj=0;j6.
7.
if（A[i].id==B[j].id）{
8.
9.
resultSet.add（A[i]）;
10.
11.
break;
12.
13.
}
14.
15.
}
16.
17.
}
18.
显然，除了使用in，我们也可以用exists实现一样的查询功能，如下：
1.
select*fromAwhereexists（select1fromBwhereA.deptId=B.deptId）;
2.
因为exists查询的理解就是，先执行主查询，获得数据后，再放到子查询中做条件验证，根据验证结果（true或者false），来决定主查询的数据结果是否得意保留。
那么，这样写就等价于：
select*fromA,先从A表做循环
select*fromBwhereA.deptId=B.deptId,再从B表做循环.
同理，可以抽象成这样一个循环：
1.
List<>resultSet;
2.
3.
for（inti=0;i4.
5.
for（intj=0;j6.
7.
if（A[i].deptId==B[j].deptId）{
8.
9.
resultSet.add（A[i]）;
10.
11.
break;
12.
13.
}
14.
15.
}
16.
17.
}
18.
数据库最费劲的就是跟程序链接释放。
假设链接了两次，每次做上百万次的数据集查询，查完就走，这样就只做了两次；相反建立了上百万次链接，申请链接释放反复重复，这样系统就受不了了。
即mysql优化原则，就是小表驱动大表，小的数据集驱动大的数据集，从而让性能更优。
因此，我们要选择最外层循环小的，也就是，如果B的数据量小于A，适合使用in，如果B的数据量大于A，即适合选择exists，这就是in和exists的区别。
20.数据库自增主键可能遇到什么问题。
▪
使用自增主键对数据库做分库分表，可能出现诸如主键重复等的问题。
解决方案的话，简单点的话可以考虑使用UUID哈
▪
▪
自增主键会产生表锁，从而引发问题
▪
▪
自增主键可能用完问题。
▪
21.MVCC熟悉吗，它的底层原理？
MVCC,多版本并发控制,它是通过读取历史版本的数据，来降低并发事务冲突，从而提高并发性能的一种机制。
MVCC需要关注这几个知识点：
▪
事务版本号
▪
▪
表的隐藏列
▪
▪
undolog
▪
▪
readview
▪
22.数据库中间件了解过吗，shardingjdbc，mycat？
▪
sharding-jdbc目前是基于jdbc驱动，无需额外的proxy，因此也无需关注proxy本身的高可用。
▪
▪
Mycat是基于Proxy，它复写了MySQL协议，将MycatServer伪装成一个MySQL数据库，而Sharding-JDBC是基于JDBC接口的扩展，是以jar包的形式提供轻量级服务的。
▪
23.MYSQL的主从延迟，你怎么解决？
嘻嘻，先复习一下主从复制原理吧，如图：
主从复制分了五个步骤进行：
▪
步骤一：
主库的更新事件（update、insert、delete）被写到binlog
▪
▪
步骤二：
从库发起连接，连接到主库。
▪
▪
步骤三：
此时主库创建一个binlogdumpthread，把binlog的内容发送到从库。
▪
▪
步骤四：
从库启动之后，创建一个I/O线程，读取主库传过来的binlog内容并写入到relaylog
▪
▪
步骤五：
还会创建一个SQL线程，从relaylog里面读取内容，从ExecMasterLog_Pos位置开始执行读取到的更新事件，将更新内容写入到slave的db
▪
主从同步延迟的原因
一个服务器开放Ｎ个链接给客户端来连接的，这样有会有大并发的更新操作,但是从服务器的里面读取binlog的线程仅有一个，当某个SQL在从服务器上执行的时间稍长或者由于某个SQL要进行锁表就会导致，主服务器的SQL大量积压，未被同步到从服务器里。
这就导致了主从不一致，也就是主从延迟。
主从同步延迟的解决办法
▪
主服务器要负责更新操作，对安全性的要求比从服务器要高，所以有些设置参数可以修改，比如syncbinlog=1，innodbflushlogattrxcommit=1之类的设置等。
▪
▪
选择更好的硬件设备作为slave。
▪
▪
把一台从服务器当度作为备份使用，而不提供查询，那边他的负载下来了，执行relaylog里面的SQL效率自然就高了。
▪
▪
增加从服务器喽，这个目的还是分散读的压力，从而降低服务器负载。
▪
24.说一下大表查询的优化方案
▪
优化shema、sql语句+索引；
▪
▪
可以考虑加缓存，memcached,redis，或者JVM本地缓存；
▪
▪
主从复制，读写分离；
▪
▪
分库分表；
▪
25.什么是数据库连接池?
为什么需要数据库连接池呢?
连接池基本原理：
数据库连接池原理：
在内部对象池中，维护一定数量的数据库连接，并对外暴露数据库连接的获取和返回方法。
应用程序和数据库建立连接的过程：
▪
通过TCP协议的三次握手和数据库服务器建立连接
▪
▪
发送数据库用户账号密码，等待数据库验证用户身份
▪
▪
完成身份验证后，系统可以提交SQL语句到数据库执行
▪
▪
把连接关闭，TCP四次挥手告别。
▪
数据库连接池好处：
▪
资源重用（连接复用）
▪
▪
更快的系统响应速度
▪
▪
新的资源分配手段
▪
▪
统一的连接管理，避免数据库连接泄漏
▪
26.一条SQL语句在MySQL中如何执行的？
先看一下Mysql的逻辑架构图吧~
查询语句：
▪
先检查该语句是否有权限
▪
▪
如果没有权限，直接返回错误信息
▪
▪
如果有权限，在MySQL8.0版本以前，会先查询缓存。
▪
▪
如果没有缓存，分析器进行词法分析，提取sql语句select等的关键元素。
然后判断sql语句是否有语法错误，比如关键词是否正确等等。
▪
▪
优化器进行确定执行方案
▪
▪
进行权限校验，如果没有权限就直接返回错误信息，如果有权限就会调用数据库引擎接口，返回执行结果。
▪
27.InnoDB引擎中的索引策略，了解过吗？
▪
覆盖索引
▪
▪
最左前缀原则
▪
▪
索引下推
▪
索引下推优化是MySQL5.6引入的，可以在索引遍历过程中，对索引中包含的字段先做判断，直接过滤掉不满足条件的记录，减少回表次数。
28.数据库存储日期格式时，如何考虑时区转换问题？
▪
datetime类型适合用来记录数据的原始的创建时间，修改记录中其他字段的值，datetime字段的值不会改变，除非手动修改它。
▪
▪
timestamp类型适合用来记录数据的最后修改时间，只要修改了记录中其他字段的值，timestamp
升级会员 