【MYSQL面试题目】

Learning_foolish

已于 2022-03-06 12:21:12 修改

阅读量378

点赞数

分类专栏： MYSQL 文章标签： mysql 面试

于 2022-02-26 20:52:32 首次发布

本文链接：https://blog.csdn.net/Learning_foolish/article/details/123150974

版权

MYSQL 专栏收录该内容

12 篇文章 0 订阅

订阅专栏

本文探讨了MySQL面试中常见的问题，包括SQL规范、B+树与B树的区别、存储引擎的选择及其特性。重点讲解了InnoDB为何使用B+树，强调了主键和自增主键的重要性，还提到了索引失效的场景及存储引擎的级别。同时，文章提及了数据量大的分页查询优化问题。

摘要由CSDN通过智能技术生成

SQL需要注意的规范

减少使用select * 语句，到底是为什么？无法使用到覆盖索引
数据量少的时候不要使用索引
少用or或in，用它查询时，mysql不一定使用索引，mysql内部优化器会根据检索比例、表大小等多个因素整体评估是否使用索引，详见范围查询优化
数据量大的时候尽量使用索引、并遵循索引的设计、使用原则：最左前缀等。具体参加《索引设计原则》、《order by优化》、《join优化》。
为什么联合左前缀原理必须要按照字段顺序使用？

为什么联合左前缀原理必须要按照字段顺序使用？

因为是排好序的，假如忽略某一个字段，单独看当前的字段值是没有顺序的，所以需要整表扫描，所以是不能使用索引的

索引分类

MySQL为什么使用B+树，而不是B树？

重要的数据结构之间的区别

概念

B-Tree：

叶子节点具有相同的深度；

叶子节点指针为空；

所有索引元素不重复；

节点中数据索引从左到右依次递增；

B+Tree：

非叶子节点不存储data，只存储索引（冗余，相当于取了部分叶子节点的元素），可以存储更多的数据；

叶子节点包含所有索引字段；

叶子节点用双向指针链接，提高访问速度

同样的数据量B+树的高度远小于B树，而树的高度决定了IO次数，从而决定了查询速度

B+树

首层：仅存放索引，叶节点 16kb，bigint-8b，文件地址-6b，一个叶子节点可以存放索引数量 = 16kb/(8+6)b=1170；

第二层：仅存放索引，叶节点 16kb，bigint-8b，文件地址-6b，一个叶子节点可以存放索引数量 = 16kb/(8+6)b=1170；

第三层：假设存放所有字段，叶节点16kb，按照1kb/行来算，可以存放16（16/1）行；

1170*1170*16 = 21902400

B树

叶节点 16kb，按照1kb/行来算，每一层可以存放16行数据，

B+树叶子节点上的指针有利于提高速度，而B树没有

MYSQL存储引擎是表级别的还是库级别的？常用的存储引擎有哪些？他们之间有什么不同？

存储引擎表级别的；

常用的存储引擎有：MYISAM、INNODB；

MYISAM、INNODB的不同主要体现在以下三点：

InnoDB支持事务，MyISAM不支持

InnoDB支持行级锁，MyISAM不支持

存储文件结构的不同：InnoDB 索引和数据在一个文件中，MyISAM不在一个文件

MYISAM有：xx.frm（表结构）, xx.MYD（数据），xx.MYI（索引）三个文件；索引的叶子节点存放的是数据的地址；

INNODB：xx.frm（表结构）,xx.ibd（索引和数据）；索引的叶子节点存放的是数据

为什么InnoDB表必须建主键，并且推荐使用整型的自增主键？

InnoDB在数据库存放的时候，必须使用B+树组织存储；假如没有设置索引，会自动选择每一行value都不同的一列作为索引列，建立索引并组织存储；若不存在这种列，则选择新建一个默认列并建立索引并组织存储。因此建议建立自增主键方便使用的同时，也可以方便数据库组织存储数据。

自增：已经排好序了，复合索引排序的要求，数据存储的时候不需要额外花时间维护索引，尤其是插入到原有已排好须的索引中，有利于提高效率。

选择整型则是因为字符号串比较大小要使用ASCII码比较，效率低；整型占用的空间相对较小。

分区为什么没有专门讲过

索引失效的场景

当表中数据不多的时候，并不一定走索引。explain 时可能出现 possible_keys 有列，而 key 显示 NULL 的情况，这种情况是因为表中数据不多，mysql认为索引对此查询帮助不大，选择了全表查询。
在索引列上做任何操作（计算、函数、（自动or手动）类型转换--类似于字符串不加单引号之类的），会导致索引失效而转向全表扫描
联合索引中违反最左前缀原理的使用。比如直接使用联合索引中的第二个字段、或者使用索引中范围条件右边的列等都无法生效。
mysql在使用不等于（！=或者<>），not in ，not exists 的时候无法使用索引会导致全表扫描
< 小于、 > 大于、 <=、>= 这些，mysql内部优化器会根据检索比例、表大小等多个因素整体评估是否使用索引
.like以通配符开头（'$abc...'）mysql索引失效会变成全表扫描操作；

场景设计题目，现在数据库数据量大没有索引，最终需要引入自增索引来解决这个问题