你好,我是李玥。
通过上节课的案例,我们知道,一个慢 SQL 就可以直接让 MySQL 瘫痪。今天这节课,我们一起看一下,怎么才能避免写出危害数据库的慢 SQL。
所谓慢 SQL,就是执行特别慢的 SQL 语句。什么样的 SQL 语句是慢 SQL?多慢才算是慢 SQL?并没有一个非常明确的标准或者说是界限。但并不是说,我们就很难区分正常的 SQL 和慢 SQL,在大多数实际的系统中,慢 SQL 消耗掉的数据库资源,往往是正常 SQL 的几倍、几十倍甚至几百倍,所以还是非常容易区分的。
但问题是,我们不能等着系统上线,慢 SQL 吃光数据库资源之后,再找出慢 SQL 来改进,那样就晚了。那么,怎样才能在开发阶段尽量避免写出慢 SQL 呢?
定量认识 MySQL
我们回顾一下上节课的案例,那个系统第一次全站宕机发生在圣诞节平安夜,故障之前的一段时间,系统并没有更新过版本,这个时候,其实慢 SQL 已经存在了,直到平安夜那天,访问量的峰值比平时增加一些,正是增加的这部分访问量,引发了数据库的雪崩。
这说明,慢 SQL 对数据库的影响,是一个量变到质变的过程,对“量”的把握,就很重要。作为一个合格的程序员,你需要对数据库的能力,有一个定量的认识。
影响 MySQL 处理能力的因素很多,比如:服务器的配置、数据库中的数据量大小、MySQL 的一些参数配置、数据库的繁忙程度等等。但是,通常情况下,这些因素对于 MySQL 性能和处理能力影响范围,大概在几倍的性能差距。所以,我们不需要精确的性能数据,只要掌握一个大致的量级,就足够指导我们的开发工作了。