【1】执行一条MySQL语句，到底发生了什么？

1.目录

a.MySQL架构
b.剖析select * from T where id=10；执行过程
3.长连接&短链接
4.解决长连接占用内存问题
5.使用查询缓存的场景

a.MySQL架构

/*
本文围绕数据库语句如下：
*/
select * from T while id=10;
select * from t1 join t2 where t1.id=t2.id;

MySQL大致可以分为两个模块：

• Server端
• 存储引擎

以下为详细架构图：

如上图所示，server端包含了连接器，分析器，优化器，执行器以及查询缓存，需要特别注意的是MySQL8.0版本之后，查询缓存这个模块被拿掉了，

看完基本架构，我们拿事例来走一下整个流程，毕竟咱伟大的领袖毛主席说过，想知道梨子的味道，就要亲口尝一尝！

b.剖析select * from T where id=10；执行过程

话不多说，

接下来，该谈谈长与短的区别了。。。

3.长连接&短链接的优缺点

• 长连接：客户端持续有请求发送，且一直使用同一个连接

• 短链接：每次执行完很少次SQL语句就断开连接，下一次有请求要发时，再重新建立连接；

  PS：建立连接有TCP的参与，三次握手建立连接，四次挥手断开连接，过程比较复杂，故而，建议尽量使用长连接

思考过多的长连接，有什么弊端？
长连接过多，会严重占用内存，一些长连接会被系统强行杀掉，也就是有时候，我们看到的MySQL异常重启。
原因很简单，MySQL在执行过程中，临时内存管理在连接对象里面，只有断开后，相应资源才会被释放；

4.解决长连接占用内存问题

前面刚说完，建立连接过程比较复杂，建议选择长连接，转身又说长连接过多，占用内存，到底哪句话是真的 ！呵，女人！

既然长连接好，但又不能多，所以，解决办法来了

• 定期断开长连接；
• MySQL5.7以上，可通过执行mysql_reset_connection重新初始化连接资源，无需重新连接和权限验证，连接自动恢复到刚建完状态；

好吧，听完这个解释，还算满意；

那问题又来了，执行SQl语句时，会先查询缓存，因为速度快啊，为啥又要避免使用缓存？缓存适合什么场景呐？

5.使用查询缓存的场景

查询缓存有一个规则，若对某表中的数据做了更新，那么与该表有关的所有缓存将全部被清空；

所以说，如果当前业务是操作一张静态表，或者长时间不会发生变更的表，采用查询缓存简直是得心应手，但如果是一张订单表，我劝你趁早住手！

使用/不使用查询缓存：
改变query_cache_type的值即可

• 不使用：DEMAND
• 使用：SQL_CACHE

好了，今日就到这里吧，希望对你有所帮助~