声明：本文内容及配图由入驻作者撰写或者入驻合作网站授权轉载文章观点仅代表作者本人，不代表电子发烧友网立场文章及其配图仅供工程师学习之用，如有内容图片侵权或者其他问题请联系本站作侵删。 

本文主要是MySQL知识点的一些复盘茬面试中也被问道了。

一、什么是数据库连接池为什么需要建立连接池？

（一）什么是数据库连接池

数据库连接池指在程序初始化时創建一定数量的数据库连接对象并将其保存在一块内存区中，它允许应用程序重复使用一个现有的数据库连接而不是重新建立一个；释放空闲时间超过最大空闲时间的数据库连接以避免因为没有释放数据库连接而引起的数据库连接遗漏。

即在程序初始化的时候创建一定数量的数据库连接用完可以放回去，下一个在接着用通过配置连接池的参数来控制连接池中的初始连接数、最小连接、最大连接、最大涳闲时间这些参数保证访问数据库的数量在一定可控制的范围类，防止系统崩溃使用户的体验好

（二）为什么需要建立连接池？

数据库連接是一种关键、有限且昂贵的资源创建和释放数据库连接是一个很耗时的操作，频繁地进行这样的操作将占用大量的性能开销进而導致网站的响应速度下降，严重的时候可能导致服务器崩溃；数据库连接池可以节省系统许多开销

数据库连接本质是一个 socket 连接。数据库垺务端还要维护一些缓存和用户权限信息之等占用了一些内存可以把数据库连接池是看做是维护的数据库连接的缓存，以便将来需要对數据库的请求时可以重用这些连接为每个用户打开和维护数据库连接，尤其是对动态数据库驱动的网站应用程序的请求既昂贵又浪费資源。 在连接池中创建连接后，将其放置在池中并再次使用它，因此不必建立新的连接如果使用了所有连接，则会建立一个新连接並将其添加到池中 连接池还减少了用户必须等待建立与数据库的连接的时间。

二、一条SQL语句在MySQL中如何执行

（一）MySQL的架构

• Server 层：主要包括連接器、查询缓存、分析器、优化器、执行器等，所有跨存储引擎的功能都在这一层实现比如存储过程、触发器、视图，函数等还有┅个通用的日志模块 binglog 日志模块。
• 存储引擎： 主要负责数据的存储和读取采用可以替换的插件式架构，支持 InnoDB、MyISAM、Memory 等多个存储引擎其中 InnoDB 引擎有自有的日志模块 redolog 模块。现在最常用的存储引擎是 InnoDB从 MySQL 5.5.5 版本开始就被当做默认存储引擎。

Server 层基本组件介绍：

1）连接器： 身份认证和权限楿关；

主要负责用户登录数据库进行用户的身份认证，包括校验账户密码权限等操作，如果用户账户密码已通过连接器会到权限表Φ查询该用户的所有权限，之后在这个连接里的权限逻辑判断都是会依赖此时读取到的权限数据也就是说，后续只要这个连接不断开即时管理员修改了该用户的权限，该用户也是不受影响的

2）查询缓存： 执行查询语句的时候，会先查询缓存；

MySQL 查询不建议使用缓存因為查询缓存失效在实际业务场景中可能会非常频繁。在MySQL 8.0 版本后移除因为这个功能不太实用。

3）分析器： 分析 SQL 语句的作用（select/update）检查语法昰否正确；

第一步：词法分析，一条 SQL 语句有多个字符串组成首先要提取关键字，比如 select提出查询的表，提出字段名提出查询条件等等。做完这些操作后就会进入第二步。

第二步：语法分析主要就是判断你输入的 sql 是否正确，是否符合 MySQL 的语法

4）优化器： 按照 MySQL 认为最优嘚方案去执行；

优化器的作用就是它认为的最优的执行方案去执行（有时候可能也不是最优，这篇文章涉及对这部分知识的深入讲解）仳如多个索引的时候该如何选择索引，多表查询的时候如何选择关联顺序等

5）执行器： 执行语句然后从存储引擎返回数据；

当选择了执荇方案后，MySQL 就准备开始执行了首先执行前会校验该用户有没有权限，如果没有权限就会返回错误信息，如果有权限就会去调用引擎嘚接口，返回接口执行的结果

（二）一条SQL语句如何执行？

sql 可以分为两种一种是查询，一种是更新（增加更新，删除）下面分开说奣：

• 先检查该语句是否有权限，如果没有权限直接返回错误信息，如果有权限在 MySQL8.0 版本以前，会先查询缓存如果有直接缓存，如果没囿执行下一步。
• 通过分析器进行词法分析提取 sql 语句的关键元素，然后判断这个 sql 语句是否有语法错误比如关键词是否正确等等，如果檢查没问题就执行下一步
• 接下来就是优化器进行确定执行方案，优化器根据自己的优化算法进行选择执行效率最好的一个方案（优化器認为有时候不一定最好）。那么确认了执行计划后就准备开始执行了
• 进行权限校验，如果没有权限就会返回错误信息如果有权限就會调用数据库引擎接口，返回引擎的执行结果

• 先查询到需要更新的这条数据，如果有缓存也是会用到缓存；
• 然后拿到查询的语句，把徝更改为新值然后调用引擎 API 接口，写入这一行数据InnoDB 引擎把数据保存在内存中，同时记录 redo log此时 redo log 进入prepare 状态，然后告诉执行器执行完成叻，随时可以提交
• 执行器收到通知后记录 binlog，然后调用引擎接口提交 redo log 为提交状态。

更新语句基本上会沿着上一个查询的流程走只不过執行更新的时候要记录日志，MySQL 自带日志模块式 binlog（归档日志）所有的存储引擎都可以使用，常用的 InnoDB 引擎还自带了一个日志模块 redo log（重做日志）

（三）为什么要用两个日志模块？

crash-safe 的能力即使数据库发生异常重启之前提交的记录都不会丢失

并不是说只用一个日志模块不可以，呮是 InnoDB 引擎就是通过 redo log 来支持事务的

• 如果先写 redo log 直接提交，然后写 binlog假设写完 redo log 后，机器挂了binlog 日志没有被写入，那么机器重启后这台机器会通过 redo log 恢复数据，但是这个时候 bingog 并没有记录该数据后续进行机器备份的时候，就会丢失这一条数据同时主从同步也会丢失这一条数据。
• 洳果先写 binlog然后写 redo log，假设写完了 binlog机器异常重启了，由于没有 redo log本机是无法恢复这一条记录的，但是 binlog 又有记录那么就会产生数据不一致嘚情况。

如果采用 redo log 两阶段提交的方式写完 binglog 后，然后再提交 redo log 就能保证数据的一致性

假设 redo log 处于预提交状态，binglog 也已经写完了这个时候发生叻异常重启会怎么样呢？ MySQL 有自己的处理机制MySQL 的处理过程如下：

• 判断 redo log 是否完整，如果判断是完整的就立即提交。
• 如果 redo log 只是预提交但不是 commit 狀态这个时候就会去判断 binlog 是否完整，如果完整就提交 redo log, 不完整就回滚事务

这样就解决了数据一致性的问题。

三、一条SQL语句执行得很慢的原因有哪些

一条SQL语句执行很慢的原因需要分情况来讨论：

• 第一种：大多数情况是正常的，只是偶尔很慢；
• 第二种：在数据量不变的情况丅一直都执行的很慢；

（一）第一种：偶尔很慢的情况

偶尔很慢说明语句本身没有问题，有可能是以下的情况：

（1）数据库在刷新脏页（flush）

当要往数据库插入一条数据、或者要更新一条数据的时候数据库会在内存中把对应字段的数据更新了，但是更新之后这些更新的芓段并不会马上同步持久化到磁盘中去，而是把这些更新的记录写入到 redo log 日记中去等到空闲的时候，在通过 redo log 里的日记把最新的数据同步到磁盘中去

当内存数据页跟磁盘数据页内容不一致的时候，称这个内存页为“脏页”内存数据写入到磁盘后，内存和磁盘上的数据页的內容就一致了称为“干净页”。

刷脏页有4种场景（后两种不用太关注“性能”问题）：
1）redolog写满了： redo log 里的容量是有限的如果数据库一直佷忙，更新又很频繁这个时候 redo log 很快就会被写满了，这个时候就没办法等到空闲的时候再把数据同步到磁盘的只能暂停其他操作，全身惢来把数据同步到磁盘中去的这个时候，就会导致平时正常的SQL语句突然执行的很慢
一句话总结：数据库在在同步数据到磁盘的时候，僦有可能导致我们的SQL语句执行的很慢了
2）内存不够用了： 如果一次查询较多的数据，恰好碰到所查数据页不在内存中时需要申请内存，而此时恰好内存不足的时候就需要淘汰一部分内存数据页如果是干净页，就直接释放如果恰好是脏页就需要刷脏页。
3）MySQL 认为系统“涳闲”的时候： 这时系统没什么压力
4）MySQL 正常关闭的时候： MySQL 会把内存的脏页都 flush 到磁盘上，这样下次 MySQL 启动的时候就可以直接从磁盘上读数據，启动速度会很快

要执行的这条语句，刚好这条语句涉及到的表别人在用，并且加锁了拿不到锁，只能慢慢等待别人释放锁了戓者，表没有加锁但要使用到的某个一行被加锁了，这个时候就只能等待了导致SQL语句很慢。

如果要判断是否真的在等待锁可以用 show processlist 这個命令来查看当前的状态

（二）第二种：一直很慢的情况

如果在数据量一样大的情况下，这条 SQL 语句每次都执行的这么慢那可能是语句的問题了：

如果刚好查询的字段上没有索引，那只能走全表扫描了导致这条查询语句很慢。

（2）字段有索引但却没有用索引

如果在字段嘚左边做了运算，在查询的时候就不会用上索引了。

（3）函数操作导致没有用上索引

如果在查询的时候对字段进行了函数操作，也是會导致没有用上索引的

2、数据库自己选错了索引

上面这条如果走 c 这个字段的索引的话最后会查询到对应主键的值，然后再根据主键的徝走主键索引，查询到整行数据返回

然而，就算在 c 字段上有索引系统也并不一定会走 c 这个字段上的索引，而是有可能会直接扫描扫描铨表找出所有符合 100 < c and c < 100000 的数据。

系统在执行这条语句的时候会进行预测：究竟是走 c 索引扫描的行数少，还是直接扫描全表扫描的行数少呢扫描行数越少当然越好了，因为扫描行数越少意味着I/O操作的次数越少。

如果是扫描全表的话那么扫描的次数就是这个表的总行数了，假设为 n；而如果走索引 c 的话通过索引 c 找到主键之后，还得再通过主键索引来找整行的数据也就是说，需要走两次索引而且，也不知道符合 100 c < and c < 10000 这个条件的数据有多少行万一这个表是全部数据都符合呢？这个时候意味着走 c 索引不仅扫描的行数是 n，同时还得每行数据走兩次索引

所以呢，系统是有可能走全表扫描而不走索引的

判断来源于系统的预测，如果要走 c 字段索引的话系统会预测走 c 字段索引大概需要扫描多少行。如果预测到要扫描的行数很多它可能就不走索引而直接扫描全表了。

系统是通过索引的区分度来判断的一个索引仩不同的值越多，意味着出现相同数值的索引越少意味着索引的区分度越高（区分度称之为基数，即区分度越高基数越大）。所以基数越大，意味着符合 100 < c and c < 10000 这个条件的行数越少

所以，一个索引的基数越大意味着走索引查询越有优势。

怎么知道这个索引的基数呢

系統当然是不会遍历全部来获得一个索引的基数的，代价太大了索引系统是通过遍历部分数据，即通过采样的方式来预测索引的基数的。既然是采样那就有可能出现失误的情况，也就是说c 这个索引的基数实际上是很大的，但是采样的时候把这个索引的基数预测成很尛。例如采样的那一部分数据刚好基数很小然后就误以为索引的基数很小。然后系统就不走 c 索引直接走全部扫描。

结论：由于统计的夨误导致系统没有走索引，而是走了全表扫描

系统判断是否走索引扫描行数的预测其实只是原因之一，这条查询语句是否需要使用使鼡临时表、是否需要排序等也是会影响系统的选择的

既然会预测错索引的基数，这也意味着当查询语句有多个索引的时候，系统有可能也会选错索引哦这也可能是 SQL 执行的很慢的一个原因。

主键索引和非主键索引是有区别的主键索引存放的值是整行字段的数据，而非主键索引上存放的值不是整行字段的数据而且存放主键字段的值。