MYSQL面试题(1-30)

2021-07-09T18:02:45
  1. MySQL 索引使用有哪些注意事项呢?

可以从三个维度回答这个问题:索引哪些情况会失效,索引不适合哪些场景,索引规则
索引哪些情况会失效

查询条件包含or,可能导致索引失效
如何字段类型是字符串,where时一定用引号括起来,否则索引失效
like通配符可能导致索引失效。
联合索引,查询时的条件列不是联合索引中的第一个列,索引失效。
在索引列上使用mysql的内置函数,索引失效。
对索引列运算(如,+、-、*、/),索引失效。
索引字段上使用(!= 或者 < >,not in)时,可能会导致索引失效。
索引字段上使用is null, is not null,可能导致索引失效。
左连接查询或者右连接查询查询关联的字段编码格式不一样,可能导致索引失效。
mysql估计使用全表扫描要比使用索引快,则不使用索引。

索引不适合哪些场景

数据量少的不适合加索引
更新比较频繁的也不适合加索引
区分度低的字段不适合加索引(如性别)

索引的一些潜规则

覆盖索引
回表
索引数据结构(B+树)
最左前缀原则
索引下推
  1. MySQL 遇到过死锁问题吗,你是如何解决的?

我排查死锁的一般步骤是酱紫的:

查看死锁日志show engine innodb status;
找出死锁Sql
分析sql加锁情况
模拟死锁案发
分析死锁日志
分析死锁结果
  1. 日常工作中你是怎么优化SQL的?

可以从这几个维度回答这个问题:

加索引
避免返回不必要的数据
适当分批量进行
优化sql结构
分库分表
读写分离
  1. 说说分库与分表的设计

分库分表方案,分库分表中间件,分库分表可能遇到的问题
分库分表方案:

水平分库:以字段为依据,按照一定策略(hash、range等),将一个库中的数据拆分到多个库中。
水平分表:以字段为依据,按照一定策略(hash、range等),将一个表中的数据拆分到多个表中。
垂直分库:以表为依据,按照业务归属不同,将不同的表拆分到不同的库中。
垂直分表:以字段为依据,按照字段的活跃性,将表中字段拆到不同的表(主表和扩展表)中。

常用的分库分表中间件:

sharding-jdbc(当当)
Mycat
TDDL(淘宝)
Oceanus(58同城数据库中间件)
vitess(谷歌开发的数据库中间件)
Atlas(Qihoo 360)

分库分表可能遇到的问题

事务问题:需要用分布式事务啦
跨节点Join的问题:解决这一问题可以分两次查询实现
跨节点的count,order by,group by以及聚合函数问题:分别在各个节点上得到结果后在应用程序端进行合并。
数据迁移,容量规划,扩容等问题
ID问题:数据库被切分后,不能再依赖数据库自身的主键生成机制啦,最简单可以考虑UUID
跨分片的排序分页问题(后台加大pagesize处理?)
  1. InnoDB与MyISAM的区别

    InnoDB支持事务,MyISAM不支持事务
    InnoDB支持外键,MyISAM不支持外键
    InnoDB 支持 MVCC(多版本并发控制),MyISAM 不支持
    select count(*) from table时,MyISAM更快,因为它有一个变量保存了整个表的总行数,可以直接读取,InnoDB就需要全表扫描。
    Innodb不支持全文索引,而MyISAM支持全文索引(5.7以后的InnoDB也支持全文索引)
    InnoDB支持表、行级锁,而MyISAM支持表级锁。
    InnoDB表必须有主键,而MyISAM可以没有主键
    Innodb表需要更多的内存和存储,而MyISAM可被压缩,存储空间较小,。
    Innodb按主键大小有序插入,MyISAM记录插入顺序是,按记录插入顺序保存。
    InnoDB 存储引擎提供了具有提交、回滚、崩溃恢复能力的事务安全,与 MyISAM 比 InnoDB 写的效率差一些,并且会占用更多的磁盘空间以保留数据和索引
    InnoDB 属于索引组织表,使用共享表空间和多表空间储存数据。MyISAM用.frm、.MYD、.MTI来储存表定义,数据和索引。

  2. 数据库索引的原理,为什么要用 B+树,为什么不用二叉树?

可以从几个维度去看这个问题,查询是否够快,效率是否稳定,存储数据多少,以及查找磁盘次数,为什么不是二叉树,为什么不是平衡二叉树,为什么不是B树,而偏偏是B+树呢?
为什么不是一般二叉树?

如果二叉树特殊化为一个链表,相当于全表扫描。平衡二叉树相比于二叉查找树来说,查找效率更稳定,总体的查找速度也更快。
为什么不是平衡二叉树呢?

我们知道,在内存比在磁盘的数据,查询效率快得多。如果树这种数据结构作为索引,那我们每查找一次数据就需要从磁盘中读取一个节点,也就是我们说的一个磁盘块,但是平衡二叉树可是每个节点只存储一个键值和数据的,如果是B树,可以存储更多的节点数据,树的高度也会降低,因此读取磁盘的次数就降下来啦,查询效率就快啦。
那为什么不是B树而是B+树呢?

1)B+树非叶子节点上是不存储数据的,仅存储键值,而B树节点中不仅存储键值,也会存储数据。innodb中页的默认大小是16KB,如果不存储数据,那么就会存储更多的键值,相应的树的阶数(节点的子节点树)就会更大,树就会更矮更胖,如此一来我们查找数据进行磁盘的IO次数有会再次减少,数据查询的效率也会更快。
2)B+树索引的所有数据均存储在叶子节点,而且数据是按照顺序排列的,链表连着的。那么B+树使得范围查找,排序查找,分组查找以及去重查找变得异常简单。
  1. 聚集索引与非聚集索引的区别

    一个表中只能拥有一个聚集索引,而非聚集索引一个表可以存在多个。
    聚集索引,索引中键值的逻辑顺序决定了表中相应行的物理顺序;非聚集索引,索引中索引的逻辑顺序与磁盘上行的物理存储顺序不同。
    索引是通过二叉树的数据结构来描述的,我们可以这么理解聚簇索引:索引的叶节点就是数据节点。而非聚簇索引的叶节点仍然是索引节点,只不过有一个指针指向对应的数据块。
    聚集索引:物理存储按照索引排序;非聚集索引:物理存储不按照索引排序;

何时使用聚集索引或非聚集索引?

  1. limit 1000000 加载很慢的话,你是怎么解决的呢?
    方案一:如果id是连续的,可以这样,返回上次查询的最大记录(偏移量),再往下limit

select id,name from employee where id>1000000 limit 10.

方案二:在业务允许的情况下限制页数:

建议跟业务讨论,有没有必要查这么后的分页啦。因为绝大多数用户都不会往后翻太多页。
方案三:order by + 索引(id为索引)

select id,name from employee order by id limit 1000000,10
SELECT a.* FROM employee a, (select id from employee where 条件 LIMIT 1000000,10 ) b where a.id=b.id

方案四:利用延迟关联或者子查询优化超多分页场景。(先快速定位需要获取的id段,然后再关联)

  1. 如何选择合适的分布式主键方案呢?

    数据库自增长序列或字段。
    UUID。
    Redis生成ID
    Twitter的snowflake算法
    利用zookeeper生成唯一ID
    MongoDB的ObjectId

  2. 事务的隔离级别有哪些?MySQL的默认隔离级别是什么?

    读未提交(Read Uncommitted)
    读已提交(Read Committed)
    可重复读(Repeatable Read)
    串行化(Serializable) Mysql默认的事务隔离级别是可重复读(Repeatable Read)

  3. 什么是幻读,脏读,不可重复读呢?

    事务A、B交替执行,事务A被事务B干扰到了,因为事务A读取到事务B未提交的数据,这就是脏读
    在一个事务范围内,两个相同的查询,读取同一条记录,却返回了不同的数据,这就是不可重复读。
    事务A查询一个范围的结果集,另一个并发事务B往这个范围中插入/删除了数据,并静悄悄地提交,然后事务A再次查询相同的范围,两次读取得到的结果集不一样了,这就是幻读。

  4. 在高并发情况下,如何做到安全的修改同一行数据?

要安全的修改同一行数据,就要保证一个线程在修改时其它线程无法更新这行记录。一般有悲观锁和乐观锁两种方案~
使用悲观锁

悲观锁思想就是,当前线程要进来修改数据时,别的线程都得拒之门外~ 比如,可以使用select…for update ~

select * from User where name=‘jay’ for update

以上这条sql语句会锁定了User表中所有符合检索条件(name=‘jay’)的记录。本次事务提交之前,别的线程都无法修改这些记录。
使用乐观锁

乐观锁思想就是,有线程过来,先放过去修改,如果看到别的线程没修改过,就可以修改成功,如果别的线程修改过,就修改失败或者重试。实现方式:乐观锁一般会使用版本号机制或CAS算法实现。

  1. 数据库的乐观锁和悲观锁。
    悲观锁:

悲观锁她专一且缺乏安全感了,她的心只属于当前事务,每时每刻都担心着它心爱的数据可能被别的事务修改,所以一个事务拥有(获得)悲观锁后,其他任何事务都不能对数据进行修改啦,只能等待锁被释放才可以执行。
乐观锁:

乐观锁的“乐观情绪”体现在,它认为数据的变动不会太频繁。因此,它允许多个事务同时对数据进行变动。实现方式:乐观锁一般会使用版本号机制或CAS算法实现。

  1. SQL优化的一般步骤是什么,怎么看执行计划(explain),如何理解其中各个字段的含义。

    show status 命令了解各种 sql 的执行频率
    通过慢查询日志定位那些执行效率较低的 sql 语句
    explain 分析低效 sql 的执行计划(这点非常重要,日常开发中用它分析Sql,会大大降低Sql导致的线上事故)

  2. select for update有什么含义,会锁表还是锁行还是其他。

select for update 含义

select查询语句是不会加锁的,但是select for update除了有查询的作用外,还会加锁呢,而且它是悲观锁哦。至于加了是行锁还是表锁,这就要看是不是用了索引/主键啦。 没用索引/主键的话就是表锁,否则就是是行锁。

  1. MySQL事务得四大特性以及实现原理

    原子性: 事务作为一个整体被执行,包含在其中的对数据库的操作要么全部被执行,要么都不执行。
    一致性: 指在事务开始之前和事务结束以后,数据不会被破坏,假如A账户给B账户转10块钱,不管成功与否,A和B的总金额是不变的。
    隔离性: 多个事务并发访问时,事务之间是相互隔离的,即一个事务不影响其它事务运行效果。简言之,就是事务之间是进水不犯河水的。
    持久性: 表示事务完成以后,该事务对数据库所作的操作更改,将持久地保存在数据库之中。

事务ACID特性的实现思想

原子性:是使用 undo log来实现的,如果事务执行过程中出错或者用户执行了rollback,系统通过undo log日志返回事务开始的状态。
持久性:使用 redo log来实现,只要redo log日志持久化了,当系统崩溃,即可通过redo log把数据恢复。
隔离性:通过锁以及MVCC,使事务相互隔离开。
一致性:通过回滚、恢复,以及并发情况下的隔离性,从而实现一致性。
  1. 如果某个表有近千万数据,CRUD比较慢,如何优化。
    分库分表

某个表有近千万数据,可以考虑优化表结构,分表(水平分表,垂直分表),当然,你这样回答,需要准备好面试官问你的分库分表相关问题呀,如

分表方案(水平分表,垂直分表,切分规则hash等)
分库分表中间件(Mycat,sharding-jdbc等)
分库分表一些问题(事务问题?跨节点Join的问题)
解决方案(分布式事务等)

索引优化

除了分库分表,优化表结构,当然还有所以索引优化等方案~

  1. 如何写sql能够有效的使用到复合索引。

复合索引,也叫组合索引,用户可以在多个列上建立索引,这种索引叫做复合索引。

当我们创建一个组合索引的时候,如(k1,k2,k3),相当于创建了(k1)、(k1,k2)和(k1,k2,k3)三个索引,这就是最左匹配原则。

select * from table where k1=A AND k2=B AND k3=D

有关于复合索引,我们需要关注查询Sql条件的顺序,确保最左匹配原则有效,同时可以删除不必要的冗余索引。

  1. mysql中in 和exists的区别。

假设表A表示某企业的员工表,表B表示部门表,查询所有部门的所有员工,很容易有以下SQL:

select * from A where deptId in (select deptId from B);

这样写等价于:

先查询部门表B select deptId from B 再由部门deptId,查询A的员工 select * from A where A.deptId = B.deptId

可以抽象成这样的一个循环:

List<> resultSet ;

for(int i=0;i<B.length;i++) {
      for(int j=0;j<A.length;j++) {
      if(A[i].id==B[j].id) {
         resultSet.add(A[i]);
         break;
      }
   }
}

显然,除了使用in,我们也可以用exists实现一样的查询功能,如下:

select * from A where exists (select 1 from B where A.deptId = B.deptId);

因为exists查询的理解就是,先执行主查询,获得数据后,再放到子查询中做条件验证,根据验证结果(true或者false),来决定主查询的数据结果是否得意保留。

那么,这样写就等价于:

select from A,先从A表做循环 select from B where A.deptId = B.deptId,再从B表做循环.

同理,可以抽象成这样一个循环:

List<> resultSet ;

for(int i=0;i<A.length;i++) {
      for(int j=0;j<B.length;j++) {
      if(A[i].deptId==B[j].deptId) {
         resultSet.add(A[i]);
         break;
      }
   }
}

数据库最费劲的就是跟程序链接释放。假设链接了两次,每次做上百万次的数据集查询,查完就走,这样就只做了两次;相反建立了上百万次链接,申请链接释放反复重复,这样系统就受不了了。即mysql优化原则,就是小表驱动大表,小的数据集驱动大的数据集,从而让性能更优。 因此,我们要选择最外层循环小的,也就是,如果B的数据量小于A,适合使用in,如果B的数据量大于A,即适合选择exists,这就是in和exists的区别。

  1. 数据库自增主键可能遇到什么问题。

使用自增主键对数据库做分库分表,可能出现诸如主键重复等的问题。解决方案的话,简单点的话可以考虑使用UUID哈 自增主键会产生表锁,从而引发问题 自增主键可能用完问题。

  1. MVCC熟悉吗,它的底层原理?

MVCC,多版本并发控制,它是通过读取历史版本的数据,来降低并发事务冲突,从而提高并发性能的一种机制。

MVCC需要关注这几个知识点:

事务版本号
表的隐藏列
undo log
read view
  1. 数据库中间件了解过吗,sharding jdbc,mycat?

sharding-jdbc目前是基于jdbc驱动,无需额外的proxy,因此也无需关注proxy本身的高可用。 Mycat 是基于 Proxy,它复写了 MySQL 协议,将 Mycat Server 伪装成一个 MySQL 数据库,而 Sharding-JDBC 是基于 JDBC 接口的扩展,是以 jar 包的形式提供轻量级服务的。

  1. MYSQL的主从延迟,你怎么解决?

    主从复制分了五个步骤进行:

    步骤一:主库的更新事件(update、insert、delete)被写到binlog
    步骤二:从库发起连接,连接到主库。
    步骤三:此时主库创建一个binlog dump thread,把binlog的内容发送到从库。
    步骤四:从库启动之后,创建一个I/O线程,读取主库传过来的binlog内容并写入到relay log
    步骤五:还会创建一个SQL线程,从relay log里面读取内容,从Exec_Master_Log_Pos位置开始执行读取到的更新事件,将更新内容写入到slave的db

主从同步延迟的原因

一个服务器开放N个链接给客户端来连接的,这样有会有大并发的更新操作, 但是从服务器的里面读取binlog的线程仅有一个,当某个SQL在从服务器上执行的时间稍长 或者由于某个SQL要进行锁表就会导致,主服务器的SQL大量积压,未被同步到从服务器里。这就导致了主从不一致, 也就是主从延迟。
主从同步延迟的解决办法

主服务器要负责更新操作,对安全性的要求比从服务器要高,所以有些设置参数可以修改,比如sync_binlog=1,innodb_flush_log_at_trx_commit = 1 之类的设置等。
选择更好的硬件设备作为slave。
把一台从服务器当度作为备份使用, 而不提供查询, 那边他的负载下来了, 执行relay log 里面的SQL效率自然就高了。
增加从服务器喽,这个目的还是分散读的压力,从而降低服务器负载。
  1. 说一下大表查询的优化方案

    优化shema、sql语句+索引;
    可以考虑加缓存,memcached, redis,或者JVM本地缓存;
    主从复制,读写分离;
    分库分表;

  2. 什么是数据库连接池?为什么需要数据库连接池呢?

连接池基本原理:

数据库连接池原理:在内部对象池中,维护一定数量的数据库连接,并对外暴露数据库连接的获取和返回方法。
应用程序和数据库建立连接的过程:

通过TCP协议的三次握手和数据库服务器建立连接
发送数据库用户账号密码,等待数据库验证用户身份
完成身份验证后,系统可以提交SQL语句到数据库执行
把连接关闭,TCP四次挥手告别。

数据库连接池好处:

资源重用 (连接复用)
更快的系统响应速度
新的资源分配手段 统一的连接管理,避免数据库连接泄漏
  1. 一条SQL语句在MySQL中如何执行的?

    先看一下Mysql的逻辑架构图吧~
    查询语句:

    先检查该语句是否有权限
    如果没有权限,直接返回错误信息
    如果有权限,在 MySQL8.0 版本以前,会先查询缓存。
    如果没有缓存,分析器进行词法分析,提取 sql 语句select等的关键元素。然后判断sql 语句是否有语法错误,比如关键词是否正确等等。
    优化器进行确定执行方案
    进行权限校验,如果没有权限就直接返回错误信息,如果有权限就会调用数据库引擎接口,返回执行结果。

  2. InnoDB引擎中的索引策略,了解过吗?

    覆盖索引
    最左前缀原则
    索引下推
    索引下推优化是 MySQL 5.6 引入的, 可以在索引遍历过程中,对索引中包含的字段先做判断,直接过滤掉不满足条件的记录,减少回表次数。

  3. 数据库存储日期格式时,如何考虑时区转换问题?

    datetime类型适合用来记录数据的原始的创建时间,修改记录中其他字段的值,datetime字段的值不会改变,除非手动修改它。
    timestamp类型适合用来记录数据的最后修改时间,只要修改了记录中其他字段的值,timestamp字段的值都会被自动更新。

  4. 一条sql执行过长的时间,你如何优化,从哪些方面入手?

    查看是否涉及多表和子查询,优化Sql结构,如去除冗余字段,是否可拆表等
    优化索引结构,看是否可以适当添加索引
    数量大的表,可以考虑进行分离/分表(如交易流水表)
    数据库主从分离,读写分离
    explain分析sql语句,查看执行计划,优化sql
    查看mysql执行日志,分析是否有其他方面的问题

  5. MYSQL数据库服务器性能分析的方法命令有哪些?

    Show status, 一些值得监控的变量值: Bytes_received和Bytes_sent 和服务器之间来往的流量。 Com_服务器正在执行的命令。 Created_在查询执行期限间创建的临时表和文件。 Handler_存储引擎操作。 Select_不同类型的联接执行计划。 Sort_*几种排序信息。
    Show profiles 是MySql用来分析当前会话SQL语句执行的资源消耗情况

当前页面是本站的「Baidu MIP」版。发表评论请点击:完整版 »