<<高性能mysql>>笔记1
转载请注明: TheViper http://www.cnblogs.com/TheViper
<<高性能mysql>>这本书写的真的很好,只可惜本屌不才,大部分都看不懂,暂且记下与mysql优化有关,对自己有用的东西。
测试指标
- 吞吐量
吞吐量指的是单位时间内的事务处理数,单位tps(transaction per second).这一直是经典的数据库应用测试的指标。
- 响应时间或延迟
这个指标用于测试任务所需的整体时间
- 并发性
注意,web服务器并发性不等同于数据库的并发性。服务器的高并发一般也会导致数据库的高并发,但服务器所用的语言,框架,工具集对此都会有影响。一个设计良好的应用,同时可以打开成千上百个数据库服务器连接,但可能同时只有少数连接在执行查询。因此,所需要关注的是正在工作中的并发操作,或者是同时工作中的线程数或连接数。
- 可扩展性
可扩展性指的是,给系统增加一倍的工作,理想情况下,会获得两倍的吞吐量,这时,看实际增加的吞吐量是多少。
性能优化的目标--响应时间
很多人认为性能优化就是降低cpu利用率。但这是个陷阱,资源就是用来消耗并用来工作的。所以,有时候消耗更多的资源能够加快查询速度。很多时候,升级到mysql新版本后,cpu利用率会上升的很厉害。这不代表性能出了问题。相反,说明新版本对资源的利用率上升了。
另外,如果把性能优化仅仅看出是提升每秒查询量,这其实只是吞吐量优化。吞吐量的提升可以减少响应时间的副产品(倒数关系)。
优化数据类型
- 更小的通常更好
一般情况下,应该尽量使用可以正确存储数据的最小数据类型。但是确保没有低估需要存储的值得范围。
- 简单就好
简单数据类型的操作通常需要更少的cpu周期。例如,整型比字符操作代价更低,具体的。
1.应该使用mysql内建类型而不是字符串存储日期和时间
2.应该用整型存储ip地址。
- 尽量避免null
通常情况下,最好指定列为not null,除非真的需要存储null值。如果查询中包含可为null的列,对mysql来说会更难优化,因为可为null的列使得索引,索引计算和值比较更复杂。另外,可为null的列会使用更多的存储空间。
下面具体说下数据类型
- 整数类型
有两种类型的数字,整数和实数。如果存储整数,可以使用这几种整数类型:TINYINT,SMALLINT,MEDIUMINT,INT,BIGINT,对应8,16,24,32,64位存储空间。
整数类型有UNSINGED属性,表示不允许负数,这大致可以是整数的最大值上限提高一倍。
mysql可以为整数类型指定宽度,如INT(7),但对大多数应用这时没意义的。它不会限制值的范围。对于存储来说,INT(1)和INT(10)是一样的。
2.实数类型
实数是带有小数部分的数字。但是,它们不仅可以用来储存小数部分,还可以使用DECIMAL储存比BIGINT还大的整数。
浮点类型在储存同样范围的值时,通常比DECIMAL使用更少的空间。FLOAT使用4个字节储存,DOUBLE使用8个字节储存。mysql使用DOUBLE作为内部浮点计算的类型。
注意,在数据量比较大时,例如储存财务数据,可以考虑使用BIGINT替代DECIMAL,将需要存储的货币单位,根据小数的位数乘以相应的倍数即可。这样可以同时避免浮点存储不精确和DECIMAL精确计算代价高的问题。
3.字符串类型
VARCHAR:用于存储可变长字符串。它比定长类型更节省空间,因为它仅使用必要的空间。
VARCHAR需要使用1或2个额外字节记录字符串的长度。如果列的最大长度<=255字节,则使用1个字节表示,否则使用2个字节。
由于行是变长的,在update时可能会使行变得比原来长。下面情况下使用VARCHAR比较合适。
1.字符串列的最大长度比平均长度大很多
2.列的更新很少,不会出现碎片问题。
3.使用了想utf-8这样复杂的字符集。
4.每个字符都使用不同的字节数进行存储。
CHAR:定长,mysql总是根据定义的字符串长度分配足够的空间。
在存储时,mysql会删除所有的末尾空格。CHAR适合存储很短的字符串,或所有值都接近同一长度。
例如,CHAR适合存储密码的md5值,因为它是定长的。对于经常变更的数据,CHAR比VARCHAR更好,因为CHAR不容易产生碎片。
4.blob和text类型
两者都是为存储很大的数据而设计的字符串数据类型,分别采用二进制和字符方式存储。
5.日期,时间类型
mysql能存储的最小时间粒度为秒。
DATETIME:这个类型能保存大范围的值,从1001年到9999年,精度为秒,它把日期和时间封装到格式为YYYYMMDDHHMMSS的整数中,与时区无关,使用8个字节的存储空间。
TIMESTAMP:这个类型保存了从1970年1月1日0时以来的秒数。它和unix时间戳相同。它使用4个字节储存,因此范围比DATETIME小很多,只能表示1970年到2038年。TIMESTAMP显示的值与时区有关。
创建高性能的索引
索引可以包含一个或多个列的值。如果索引包含多个列,那列的顺序十分重要,因为mysql只能高效的使用索引的最左前缀列。
最常见的B-Tree索引,按照顺序存储数据,所以mysql可以做order by和group by操作。因为数据是有序的,所以B-Tree也会将相关的列值都存储在一起。最后,因为索引中存储了实际的值,所以某些查询只使用索引,就能够完成全部查询。
策略:
1.独立的列:索引列不能是表达式的一部分,也不能是函数的参数。比如,
select id from a where id+1=5
select .... where TO_DAYS(CURRENT_DATE)-TO_DAYS(date_col)<=10
应该养成简化where条件的习惯,始终将索引列单独放在比较符号的一侧。
2.前缀索引:索引开始的部分字符。
对于像BLOB,TEXT这种很长的列,必须使用前缀索引。因为mysql不允许索引这些列的完整长度。
因此建立前缀索引的关键是,选择足够长的前缀,以保证较高的选择性,同时又不能太长。
前缀应该足够长,以使得前缀索引的选择性接近于索引整个列。为了找出这个足够长度,需要找到最常见的值的列表,然后和最常见的前缀列表进行比较。例如
可以看到每个值都在45到65之间,区分度不好。下面取3个前缀字符
这次区分度就要好点了,下面继续增加前缀长度,最后发现前缀长度为7时比较合适
计算合适前缀长度的另一个方法是计算完整列的选择性,并使前缀的选择性接近于完整列的选择性,具体的
3.多列索引
一个常见的错误是,为每个列创建一个单独的索引,或按照错误的顺序创建多列索引。
关于索引列的顺序,正确的顺序依赖于使用该索引的查询,同时还要考虑是否满足排序和分组的需要。
一个经验:将选择性最高的列放在索引的最前列。这个经验在不需要考虑排序和分组的时候效果很好。这时候索引的作用只是在优化where条件的查找。
事实上,性能不只是依赖于所有索引列的选择性,也和查询条件的具体值有关,也就是和值分布有关,这和前面说的选择最佳前缀长度需要考虑的地方一样。换句话说,可能需要根据那些运行频率最高的查询来调整索引列的顺序。
使用索引扫描排序
mysql有两种方式生成有序结果,通过排序操作或按索引顺序扫描。如果explain出来的type列的值为index,说明使用了索引扫描做排序。
扫描索引本身是很快的,因为只需要从一条索引记录移动到紧接的下一条记录。但如果索引不能覆盖查询所需的全部列,那就不得不每扫描一条索引记录就回表查询一次对应的行。这基本上都是随机的io.因此按索引顺序读取数据的速度通常比顺序的全表扫描慢,尤其是在io密集型的工作负载中。
mysql可以使用同一个索引既满足排序,又用于查找行。因此,如果可能,设计索引时应该尽可能的满足这两种任务最好。
只有当索引的顺序和order by子句的顺序完全一致,并且所有列的排列方向都一样时,mysql才能使用索引对结果排序。
如果查询需要关联多张表,则只有当order by子句引用的字段全部为第一个表时,才能使用索引做排序。
order by子句和查找性查询的限制是一样的,需要满足索引的最左前缀的要求,否则,mysql都需要执行排序操作。
有一种情况可以不满足索引的最左前缀要求,依然可以使用索引排序。那就是当前导量为常数时。例如
在一个表上,建立索引(a,b,c)。
select ... where a=“2014-12-21” order by b,c.
这时索引的第一列被指定为常数,可以使用索引。下面的也可以使用索引
select ... where a>"2014-12-21" order by b
select ... where a>"2014-12-21" order by a,b
这两个刚好用了索引的前缀,所以也可以。
下面是一些不能使用索引进行排序的查询
select ... where a="2014-12-21" order by b DESC,c ESC
查询使用了两种不同的排序方向,但是索引列都是正序排序的。
select ... where a="2014-12-21" order by b,d
引用了一个不在索引中的列
select ... where a="2014-12-21" order by c
where和order by中的列无法组成索引的最左前缀,因为跳过了b这个列
select ... where a>"2014-12-21" order by b,c
第一列是范围查询
select ... where a>"2014-12-21" and b in(1,2) order by c
b列上有多个等于条件
郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。