找工作再也不愁之面试题全覆盖-数据库篇

Posted 2022-01-08 墨家巨子@俏如来

数据库基础

求平局值用什么，分组用什么

统计平局值：avg

分组：group by

两个结果集求并集用什么

union 并集 , union all(允许重复)

完整查询SQL中的关键字的定义顺序

SELECT 列名 FROM 表1 JOIN 表2 ON 条件 WHERE 条件 GROUP BY 列名 HAVING 条件 ORDER BY 列名 LIMIT

完整的多表JOIN查询，SQL中关键字的执行顺序

FROM --> ON --> JOIN --> WHERE --> GROUP BY --> HAVING --> ORDER BY --> LIMIT

索引部分

什么是索引

索引是用来高效获取数据的存储结构如同字典的目录一样，数据库的索引通常使用b+tree来实现，索引树的节点和数据地址相关联，查询的时候在索引树种进行高效搜索，然后根据数据地址获取数据。索引提高了搜索的效率同时增加了索引维护的成本，滥用索引也会降低insert,update,delete的性能。

mysql索引有哪些类型

普通索引：允许重复的值

唯一索引：不允许有重复的值

主键索引：数据库自动为我们的主键创建索引，如果我们没有指定主键，它会根据没有null的唯一索引创建主键索引，否则会默认根据一个隐藏的rowId作为主键索引

全文索引，用来对文本域进行索引，比如text，varchar，只针对MyISAM有效

索引方式有哪些

B+树和hash，Myisam和innodb都不支持hash

Mysql的索引结构原理

采用了B+树的数据结构,采用B+树的原因，B+树是多叉树，适合存储大量数据，B+树的数据存储在叶子节点，内部节点只存键值，因此B+树每次查询都要走到叶子节点， 查询性能更稳定，同时它的非叶子节点只存储key，因此每个节点能存储更多的key，树的高度变的更低，查询性能更快，而且它的叶子节点能够形成一个链表，支持范围查询，排序 。

InnoDB的索引结构和MyIsam的索引结构有什么区别

他们都是用的B+树，不同的是

• innodb的叶子节点存放的是数据，myisam的叶子节点存放的是数据的地址
• innodb中辅助索引的叶子节点存放的是主键索引的键值，myisam中辅助索引的叶子节点存放的也是数据的地址
• innodb的索引和数据都存放到一个文件中，myisam的索引和数据分别存放到不同的文件中

哪些列不适合创建索引

不经常查询的列不适合创建索引

不出现在where中的字段不适合创建索引

离散度太低的字段不适合创建索引，比如性别

更新非常频繁的字段不适合创建索引，因为会导致索引频繁更细，性能差。

哪些因素会造成索引失效

模糊查询时，通配符放到左边的时候，会导致索引失效 比如 like ‘’%keyword%’’

列是字符串类型，查询条件没有用引号，会导致索引失效

使用了or，in，not in，not exist， !=等，会导致索引失效

查询null值，会导致索引失效

还有mySQL认为全表扫描会比索引查找快，就不会使用索引，比如表里只有一条记录

什么是辅助索引&什么是覆盖索引

除了主键索引之外的其他索引都叫辅助索引，也叫二级检索。辅助索引的叶子节点存储的是主键索引的键值，因此辅助索引扫描完之后还会扫描主键索引，这也叫回表

但是如果查询的列恰好包含在辅助索引的键值中，就不会再回表了，这也叫覆盖索引

InnoDB辅助索引的叶子节点也存数据吗

InnoDB辅助索引的叶子节点存放的是，主键索引的键值

因此辅助索引扫描完还会扫描主键索引，也叫回表

但是如果查询的列恰好包含在辅助索引的键值中，就不会再回表了，这也叫覆盖索引

组合索引的匹配原则

组合索引向左匹配，我们应该优先选择组合索引，因为对覆盖索引命中率更高，查询性能更高，但是应该考虑列的顺序，因为组合索引会向左匹配

Like一定会让索引失效吗

不一定，比如：like “值%” 一样可以使用索引，向左匹配，而 like "%值"或 "_值"就不能命中索引。

索引创建的原则有哪些

查询较频繁的列应该考虑创建索引

不经常查询的列不适合创建索引

不出现在where中的字段不适合创建索引

离散度太低的字段不适合创建索引，比如性别

更新非常频繁的字段不适合创建索引

数据库优化

哪些因素可能会造成数据库性能问题

不合理的商业需求，比如实时更新总注册人数，总交易额等等，应该考虑不要实时

对于热点数据的查询并发太高，应该考虑用缓存

数据库结构设计不合理，比如几十个字段集中在一张表，应该考虑分表

SQL语句有问题，比如太多JOIN，很多不需要的字段也要全部查询出来，应该考虑优化SQL

硬件和网络方面的影响

Mysql的执行流程是怎么样的

客户端发起SQL查询，首先通过连接器，它会检查用户的身份，包括校验账户密码，权限

然后会查询缓存，如果缓存命中直接返回，如果没有命中再执行后续操作，但是MySQL8.0之后已经删除了缓存功能

接下来到达分析器，主要检查语法词法，比如SQL有没有写错，总共有多少关键字，要查询哪些东西

然后到达优化器，他会以自己的方式优化我们的SQL

最后到达执行器，调用存储引擎执行SQL并返回结果

优化SQL你从哪些方面着手

不需要的字段就不要查询出来

小结果集驱动大结果集，将能过率更多数据的条件写到前面

in和not in尽量不要用，会导致索引失效

避免在where中使用or链接条件，这会导致索引失效

给经常要查询的字段建立索引

考虑如果不需要事务，并且主要查询的化，可以考虑使用MyISAM存储引擎

如果表数据量实在太庞大了，考虑分表

如何去定位慢SQL

通过druid连接池的内置监控来定位慢SQL

通过MySQL的慢查询日志查看慢SQL

通过show processlist，查看当前数据库SQL执行情况来定位慢SQL

页面上发起的一个查询很慢，你怎么去优化

首先看一下硬件和网络层面，有没有什么异常

然后分析代码有没有什么问题，算法有没有什么缺陷，比如多层嵌套循环

最后我们再定位到慢SQL，比如

• 通过druid连接池的内置监控来定位慢SQL
• 通过MySQL的慢查询日志查看慢SQL
• 通过show processlist，查看当前数据库SQL执行情况来定位慢SQL

定位到慢SQL再考虑优化该SQL，比如说

• 不需要的字段就不要查询出来
• 小结果集驱动大结果集，将能过率更多数据的条件写到前面
• in和not in尽量不要用，会导致索引失效
• 避免在where中使用or链接条件，这会导致索引失效
• 考虑如果不需要事务，并且主要查询的化，可以考虑使用MyISAM存储引擎

如果优化SQL后还是很慢，可以考虑给查询字段建索引来提升效率

如果建立索引了还是慢，看一下是不是数据量太庞大了，应该考虑分表了

你如何看SQL有没有命中索引

在SQL语句前加上explain，结果中的key就是实际用到的索引

mysql存储引擎有哪些，有什么区别，如何选择

主要有innodb，memory，myisam

innodb支持事务，速度相对较慢，支持外键，不支持全文索引

myisam 速度相对较快，支持全文索引，不支持外键，不支持事务，

memory不支持事务，基于内存读写，速度快，支持全文索引

如果对事务要求不高，而且是查询为主，考虑用myisam

如果对事务要求高，保存的都是重要的数据，建议使用innodb，它也是默认的存储引擎

如果数据频繁变化的，不需要持久化，可以使用memory

下面SQL如何优化

一个sql ： select sum(amount) from recharge ,来查询总充值，recharge 表数据量达到了上千万，怎么优化

可以考虑建个汇总表来统计总充值，总订单数，总人数等等等

或者采用日报表，月报表，年报表，使用定时任务进行结算的方式来统计

或者看数据能不能使用ES搜索引擎来优化，如果非得要在这个上千万的表中来查询，那就采用分表

事务相关

什么是事务

一组对数据库的操作，把这一组看成一个再给你，要么全部成功，要么全部失败。

举个栗子，比如A向B转账，A账户的钱少了，B账户的钱就应该对应增加，这就转账成功了，如果A账户的钱少了，由于网络波动等因素转账失败了，B账户的钱没有增加，那么A账户就应该恢复成原先的状态

事务的四大特性

原子性：指的是一个事务应该是一个最小的无法分割的单元，不允许部分成功部分失败，只能同时成功，或者同时失败

持久性：一旦提交事务，那么数据就应该持久化，保证数据不会丢失

隔离性：两个事务修改同一个数据，必须按顺序执行，并且前一个事务如果未完成，那么中间状态对另一个事务不可见

一致性：要求任何写到数据库的数据都必须满足预先定义的规则，它基于其他三个特性实现的

InnoDB如何保证原子性和持久性的

通过undo log 保证事务的原子性，redo log保证事务的持久性

undo log是回滚日志，记录的是回滚需要的信息，redo log记录的是新数据的备份

当事务开始时，会先保存一个undo log，再执行修改，并保存一个redo log，最后再提交事务。如果系统崩溃数据保存失败了，可以根据redo log中的内容，从新恢复到最新状态，如果事务需要回滚，就根据undo log 回滚到之前的状态

事务并发问题有哪些

脏读：事务A读到了事务B修改还未提交的数据

幻读，也叫虚读：事务A两次读取相同条件的数据，两次查询到的数据条数不一致，是由于事务B再这两次查询中插入或删除了数据造成的

不可重复读：事务A两次读取相同条件的数据，结果读取出不同的结果，是由于事务B再这两次查询中修改了数据造成的

第一类丢失更新：也叫回滚丢失，事务A和事务B更新同一条数据，事务B先完成了修改，此时事务A异常终止，回滚后造成事务B的更新也丢失了

第二类丢失更新：也叫覆盖丢失，事务A和事务B更新同一条数据，事务B先完成了修改，事务A再次修改并提交，把事务B提交的数据给覆盖了

事务隔离级别有哪些，分别能解决什么问题

读未提交：事务读不阻塞其他事务的读和写，事务写阻塞其他事务的写但不阻塞读，能解决第一类丢失更新的问题，

读已提交：事务读不会阻塞其他事务读和写，事务写会阻塞其他事务的读和写，能解决第一类丢失更新，脏读的问题

可重复读：事务读会阻塞其他事务的写但不阻塞读，事务写会阻塞其他事务读和写，能解决第一类丢失更新，脏读，不可重复读，第二类丢失更新问题

串行化：使用表级锁，让事务一个一个的按顺序执行，能解决以上所有并发安全问题

MySql的InnoDB是如何保证原子性的

利用了undo log实现的

undo log记录了这些回滚需要的信息，当事务执行失败或调用了rollback，导致事务需要回滚，就可以利用undo log中的信息将数据回滚到修改之前的样子

MySql的InnoDB是如何保证持久性的

利用了redo log实现的

redo log记录的是新数据的备份，在事务提交前，需要将Redo Log持久化，当系统崩溃时，可以根据redo Log的内容，将所有数据恢复到最新的状态

说一下事务的执行流程(Undolog+Redolog)

假设有A=1，B=2，两个数据，现在有个事务把A修改为3，B修改为4，那么事务的执行流程：

当事务开始时，会首先记录A=1到undo log，记录A=3到redo log，和记录B=2到undo log，记录B=4到redo log，然后再将redo log写入磁盘，最终事务提交

解释一下事务并发丢失更新问题，·如何解决

第一类丢失更新：也叫回滚丢失，事务A和事务B更新同一条数据，事务B先完成了修改，此时事务A异常终止，回滚后造成事务B的更新也丢失了

第二类丢失更新：也叫覆盖丢失，事务A和事务B更新同一条数据，事务B先完成了修改，事务A再次修改并提交，把事务B提交的数据给覆盖了

SQL标准中的四种隔离级别，读未提交，读已提交，可重复读，串行化，都能解决第一类数据更新丢失问题

对于第二类丢失更新问题，可以使用悲观锁也就是串行化来解决，也可以使用乐观锁的方式，比如加一个版本号管理来解决

InnoDB事务隔离的实现原理是什么

隔离的实现主要利用了读写锁和MVCC机制

读写锁，要求在每次读操作时需要获取一个共享锁，写操作时需要获取一个写锁。共享锁之间不会产生互斥，共享锁和写锁，写锁与写锁之间会产生互斥。当产生锁竞争时，需要等一个操作的锁释放，另一个操作才能获得锁

MVCC，多版本并发控制，它是在读取数据时通过一种类似快照的方式将数据保存下来，不同的事务看到的快照版本是不一样的，即使其他事务修改了数据，但是对本事务仍然是不可见的，它只会看到第一次查询到的数据

可重复读是只在事务开始的时候生成一个当前事务全局性的快照，而读提交则是每次执行语句的时候都重新生成一次快照

数据库集群

Mysql主从解决什么问题，不能解决什么问题？

MySQL主从同步，主负责写，从负责读，使用一主多从，能减轻读的压力

但是这不能解决写的压力和主库的单点故障，如果主库的写并发高，可以做成多个主库

MySql主从复制原理？

主要依靠binlog来实现的，它记录的是所有的DDL，DML，TCL操作

当主库的数据发生改变时，会将改变记录保存到binlog中

从库新开一个线程将binlog内容发送到从库

从库会发起一个I/O线程请求主库的binlog，并保存到中继日志中

从库新开一个SQL线程，读取中继日志并解析成具体操作，从而将主库更新的内容写到了从库中

MySql主从配置步骤？

安装mySQL主从客户端，并配置my.ini

主库需要配置授权从库使用的账号和权限，启动后可以通过show 主库名 status查看状态，我们需要记录File和Position的值，File是对应的binlog文件名，position是当前同步数据的最新行

从库需要配置主库链接信息，包括账号密码和binlog文件名和最新行，然后启动。通过show 从库名 status 检查同步状态，Slave_IO_Running 和 Slave_SQL_Running 的值都为YES，说明大功告成了

什么是垂直分表，垂直分库，水平分表，水平分库

垂直分表，可以理解为按列分表，如果一个表的字段太多了，可以按照使用频率分成不同的表，优化查询性能。比如商品表可以分为商品类型表，商品详情表，商品促销表等等

垂直分库，为了减轻单个数据库压力，我们可以按照业务类型，拆分成多个数据库，比如分布式架构，不同的模块可以有不同的数据库

水平分表，可以理解为按行分表，如果一个表的数据有千万行，查询性能太低，可以拆分成10张小表，每张表保存一百万行数据

水平分库，我们做了水平分表后，表数量太多了也会影响数据库查询效率，我们可以将这些表分到多个数据库中

分库分表后会出现哪些问题？怎么解决

会产生分布式事务，以前本地事务就能结局的问题现在要用上Seata分布式事务

垂直分库后跨库查询会导致一个查询结果来源于两个库，可能要用到多线程调用多个库查询

水平分库后一个分页查询的某一页可能来自两个库，可以将两个库的数据合并之后再执行SQL

水平分表后不同的表出现主键重复，可以通过雪花算法来解决

两个库都用到同一个表，那这个公共表的维护可能要用到MySQL主从同步

你们公司使用的是什么技术来水平分表？还可以有什么技术？有什么区别？

使用的是sharding-jdbc来实现的，它是由java开发的关系型数据库中间件，读写分离，分库分表操作简单

TDDL，淘宝业务框架，复杂而且分库分表的部分还没有开源

Mycat，要安装额外的环境，不稳定用起来复杂

MySQL官方提供的中间件，不支持大数据量的分不分表，性能较差

你们使用什么规则来分库分表的？还有哪些规则？

垂直分库，按照业务进行垂直分库，比如课程表和用户表放到不同数据库

垂直分表，把多字段表拆分少量字段表，比如将课程表分为课程类型表，课程详情表，课程促销表等

水平分表，把海量数据表拆分为多个小表

把商品业务进行水平分库，可以对水平分库后每一个数据库服务器进行集群

你从哪些方面去优化你的数据库？

如果是并发高，可以考虑缓存，如果是数据量大可以考虑分库分表，具体如下：

首先应该考虑垂直分库，不同的业务使用不同的数据库

然后进行垂直分表，按照使用频率把字段多的表拆分成若干个表

对经常查询的列建立索引，提高查询效率

设计冗余字段，减少join表的次数

SQL优化，比如尽量使用索引查询

对热点数据应该考虑做缓存，比如首页展示汇总数据

从海量数据中查询数据应该考虑用全文检索

如果查询并发高，可以对mySQL做集群

如果数据量实在太大了，可以考虑水平分表，

水平分表后，表数量还是太多了，可以考虑水平分库

Mysql的集群有哪些模式？

一主一从；一主多从；双主；环形多主；级联同步

单机优化到极致了，可以怎么优化？

可以考虑做集群，比如一主多从模式，然后对应用做读写分离

多机优化有哪些方式？

分表，分库，主从同步

解释一下分库分表的含义？

垂直分表，可以理解为按列分表，如果一个表的字段太多了，可以按照使用频率分成不同的表，优化查询性能。比如商品表可以分为商品类型表，商品详情表，商品促销表等等

垂直分库，为了减轻单个数据库压力，我们可以按照业务类型，拆分成多个数据库，比如分布式架构，不同的模块可以有不同的数据库

水平分表，可以理解为按行分表，如果一个表的数据有千万行，查询性能太低，可以拆分成10张小表，每张表保存一百万行数据

水平分库，我们做了水平分表后，表数量太多了也会影响数据库查询效率，我们可以将这些表分到多个数据库中

水平分表有哪些分表规则？

按照区间范围分表，比如把用户按照年龄分为新生代表，青年代表，老年代表

按照时间分表，比如按照年来分表，比如登录日志，分成今年的表，去年的表。。

hash分表，通过将某一列的值比如id，通过一定的hash算法来算出对应那张表

雪花算法，通过雪花算法生成id，根据id来算出对应那张表

能简单说一下你怎么使用shardingjdbc做读写分离的嘛

首先导入相关的依赖

然后在配置文件中配置datasource，包括主从数据库的名字，主从数据库的连接信息，配置负载均衡

项目中就可以正常使用datasource了，自动做读写分离

能简单说一下你怎么使用shardingjdbc做读分库分表的嘛

首先，要改造数据库，比如水平分表，水平分库

在配置文件中，需要做如下配置

• datasource名字，多个数据源就配多个datasource
• 分库策略，比如按照哪一列分库，分库规则
• 分表策略，比如哪些库下面的哪些表，按照那一列分表，分表规则
• 配置公共的表

然后项目中就可以正常使用了