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
好了,今日就到这里吧,希望对你有所帮助~