MariaDB Tuning

MariaDB性能优化

Query Profiling,即查询分析技术,是 MySQL 数据库提供的一种诊断 SQL 性能的方法,同时也被视为分析数据库整体性能的有效技术。 用户可以在开启 Profiling 的情况下,查看当前会话中 SQL 执行时间消耗分布,系统时间,CPU 用户时间,以及过程中涉及到的关键函数在源代码文件中的定位等。 由于单个大中型应用程序可以在单位时间内完成多个查询,因此 Query Profiling 是数据库优化调整的重要组成部分,它既可作为数据库性能优化的积极主动措施,亦可用于诊当前断数据库性能是否存在问题。 在实际工作场景中,如果不采用可靠的查询分析技术,相关技术人员往往很难定位数据库中性能瓶颈及性能不佳问题的根源所在。 作为 MySQL 的一个分支,MariaDB Server 自带的内置工具中为我们提供了 Query Profiling 相关的查询概要分析技术。 我们以 Slow Query Log(慢速查询日志)和 Performance Schema(性能策略模型)这两类 MariaDB Server 内置工具为例,深入探索查询分析技术的价值。 MariaDB vs MySQL 首先让我们来回顾一下 MariaDB 和 MySQL 这两种产品间的亲属关系。 早在 2010 甲骨文宣布收购 Sun 公司的那天,MySQL 之父 Michael“Monty”Widenius就派生了 MySQL,进而推出 Read more…

MySQL Tuning

MySQL性能调试必须掌握的语句:explain

explain是MySQL性能调优过程中必须掌握的工具,今天花1分钟简单说下,explain结果中常见的type结果及代表的含义,并且通过同一个SQL语句的性能差异,说明建立正确的索引多么重要。 explain结果中的type字段代表什么意思?​ MySQL的官网解释非常简洁,只用了3个单词:连接类型(the join type)。它描述了找到所需数据使用的扫描方式。 最为常见的扫描方式有: 画外音:这些是最常见的,大家去explain自己工作中的SQL语句,95%都是上面这些类型。​ 上面各类扫描方式由快到慢: system > const > eq_ref > ref > range > index > ALL​ 下面一一举例说明。 一、system​ 上例中,从系统库mysql的系统表time_zone里查询数据,扫码类型为system,这些数据已经加载到内存里,不需要进行磁盘IO。 这类扫描是速度最快的。 再举一个例子,内层嵌套(const)返回了一个临时表,外层嵌套从临时表查询,其扫描类型也是system,也不需要走磁盘IO,速度超快。 二、const​ 数据准备: const扫描的条件为: 如上例,id是PK,连接部分是常量1。 画外音:这里注意,防止隐式类型转换。 这类扫描效率极高,返回数据量少,速度非常快。 三、eq_ref​ 数据准备: eq_ref扫描的条件为,对于前表的每一行(row),后表只有一行被扫描。 再细化一点: 如上例,id是主键,该join查询为eq_ref扫描。 这类扫描的速度也异常之快。 四、ref​ 数据准备: 如果把上例eq_ref案例中的主键索引,改为普通非唯一(non unique)索引。 就由eq_ref降级为了ref,此时对于前表的每一行(row),后表可能有多于一行的数据被扫描。 当id改为普通非唯一索引后,常量的连接查询,也由const降级为了ref,因为也可能有多于一行的数据被扫描。 ref扫描,可能出现在join里,也可能出现在单表普通索引里,每一次匹配可能有多行数据返回,虽然它比eq_ref要慢,但它仍然是一个很快的join类型。 五、range​ 数据准备: range扫描就比较好理解了,它是索引上的范围查询,它会在索引上扫描特定范围内的值。 像上例中的between,in,>都是典型的范围(range)查询。 画外音:必须是索引,否则不能批量”跳过”。 Read more…