一条MySQL的查询、更新，都经历了什么？

        通过一条简单的SQL语句，就能查到我们需要的数据，MySQL是如何实现的呢？对于更新语句，innodb存储引擎是如何保证数据一致性的呢？带着这俩个问题，让我们一起学习一起飞。

       你可能是开发人员，或者是测试人员，或者是产品经理，每天都会熟练的打开MySQL客户端，连接到数据库，去运行SQL。

       一条select语句在mqsql的执行流程：第一步就是通过MySQL客户端连接到数据库；第二步编写我们的SQL；第三步点击运行该SQL。OK，我们要了解查询语句的执行流程的关键，就是要理清第三步的运行过程都经历了什么？

      MySQL有server层，与引擎层。server层由连接器、查询缓存器、分析器、优化器、执行器组成。而常见的引擎层有innodb、myisqm存储引擎，文章中主要关注当下最流行的innodb存储引擎。当我们通过连接器连接到数据库后，查询缓存器会通过我们的SQL语句，在内存中去查找是否有结果，若有则直接返回；若无，则通过分析器检查我们的SQL的词法、语法是否合法（如关键字是否拼写正确，查询的字段是否存在等），若不合法，则会返回错误提示。若合法，则会进入优化器，在执行前，对SQL进行执行优化（这里的优化，指的是使用哪个索引进行查询，或是join语句的执行优化，之后的文章会讲到），形成执行计划。优化完成后，执行器通过引擎层（innodb）对外提供的读写接口执行进行读取。引擎层通过在B+TREE的数据结构下，查找到数据页信息，将结果返回。至此，一个查询流程执行完毕。

       这里需要关注下查询缓存器这个组件，它可以将查询过的数据缓存起来，减少IO成本，增加查询速度。但当这个表的某条数据发生了更新，那这个表的之前建立的所有缓存将失效，注意这里说的是所有。所以查询缓存器适合于读多写少的操作，若更新多，则不适合。我们可以通过查看数据库的参数“query_cache_type”看我们的数据库是否开启了查询缓存，on为开启，off为关闭，我敢肯定你的线上库一定是off的状态，为什么呢？你可以想象一下在开发过程中哪些数据是极少更新的，那就是配置信息。虽然你的配置信息在库中保存着，但为了减少对数据库的操作，肯定在基于内存的数据库中也同步着一份。如果没有的话，那你下个迭代的首要任务就是将它同步到内存中一份。那你会问，查询缓存器还有说什么存在的价值呢？没价值还不如直接把它干掉嘛！所以， MySQL8.0版本已经彻底删除了这个组件。

       连接器：想必接触过spring框架的你，一定经常在配置文件中看到数据库连接池。说到“池”，你可能会联想到线程池。在说连接池时，我们先来聊聊线程池。首先，为什么要有线程池？因为它已经帮我们提前创建好了线程，不需要系统需要的时候再去创建，提高了程序的执行速度。当遇到并发较高，执行时间较短的场景，如果过来一个请求就创建一个线程，一时间就会创建大量线程，就会出现大量的cpu切换线程出现，从而浪费了大量时间，也占据了很多系统资源。此时线程池的作用就显而易见了。我们再切换到数据库连接池，同理，它也在时间与空间上面做了很大贡献。时间上，减少了创建连接的时间；空间上，防止大量连接请求去创建连接，当请求数>连接数，多出的请求将排队等待，这也降低了数据库的压力，可以有时间去做其它事情。

       优化器：主要优化了索引的选择，与join联表时的优化过程。之后会有单独的文章来讲解。

       查询语句相关的就告一段落，接下来聊聊更新语句。

       对于一个更新语句，它也是要有查询操作的。先查到数据返回，接下来再更新写入。我们主要关注更新写入的过程。

       这里有两个日志文件需要先了解下。一个是redo log，另一个是binlog。redo log是innodb特有的日志，binlog存在于server层，也即是说，MySQL肯定有binlog，是否有redo log 视存储引擎而定。

       进行更新操作时，第一步先调用innodb的写接口，将更新操作写入redo log里，状态记为prepare。第二步server层将更新写入binlog中，并调用innodb的提交接口。第三步将redo log里状态为prepare的记录更新为commit状态。一个更新操作完成，这也是著名的“两阶段提交”，以此来保证数据的一致性。

      未完待续。。。