search 2013 adfgs

接着上一篇 MySQL 数据库性能优化之SQL优化,这是 MySQL数据库性能优化专题 系列的第五篇文章:MySQL数据库性能优化之存储引擎选择 离上一篇文章已经有很长时间没有更新这个MySQL数据库性能优化专题了,时间太紧加上人之惰性,今天这里将之前就规划好的关于存储引擎选择方面的内容更新出来,希望对大家有所帮助吧 MySQL 的存储引擎可能是所有关系型数据库产品中最具有特色的了,不仅可以同时使用多种存储引擎,而且每种存储引擎和MySQL之间使用插件方式这种非常松的耦合关系。 由于各存储引擎功能特性差异较大,这篇文章主要是介绍如何来选择合适的存储引擎来应对不同的业务场景。 MyISAM 特性 不支持事务:MyISAM存储引擎不支持事务,所以对事务有要求的业务场景不能使用 表级锁定:其锁定机制是表级索引,这虽然可以让锁定的实现成本很小但是也同时大大降低了其并发性能 读写互相阻塞:不仅会在写入的时候阻塞读取,MyISAM还会在读取的时候阻塞写入,但读本身并不会阻塞另外的读 只会缓存索引:MyISAM可以通过key_buffer缓存以大大提高访问性能减少磁盘IO,但是这个缓存区只会缓存索引,而不会缓存数据 适用场景 不需要事务支持(不支持) 并发相对较低(锁定机制问题) 数据修改相对较少(阻塞问题) 以读为主 数据一致性要求不是非常高 最佳实践 尽量索引(缓存机制) 调整读写优先级,根据实际需求确保重要操作更优先 启用延迟插入改善大批量写入性能 尽量顺序操作让insert数据都写入到尾部,减少阻塞 分解大的操作,降低单个操作的阻塞时间 降低并发数,某些高并发场景通过应用来进行排队机制 对于相对静态的数据,充分利用Query Cache可以极大的提高访问效率 MyISAM的Count只有在全表扫描的时候特别高效,带有其他条件的count都需要进行实际的数据访问 InnoDB 特性 具有较好的事务支持:支持4个事务隔离级别,支持多版本读 行级锁定:通过索引实现,全表扫描仍然会是表锁,注意间隙锁的影响 读写阻塞与事务隔离级别相关 具有非常高效的缓存特性:能缓存索引,也能缓存数据 整个表和主键以Cluster方式存储,组成一颗平衡树 所有Secondary Index都会保存主键信息 适用场景 需要事务支持(具有较好的事务特性) 行级锁定对高并发有很好的适应能力,但需要确保查询是通过索引完成 数据更新较为频繁的场景 数据一致性要求较高 硬件设备内存较大,可以利用InnoDB较好的缓存能力来提高内存利用率,尽可能减少磁盘 IO 最佳实践 主键尽可能小,避免给Secondary index带来过大的空间负担 避免全表扫描,因为会使用表锁 尽可能缓存所有的索引和数据,提高响应速度 在大批量小插入的时候,尽量自己控制事务而不要使用autocommit自动提交 合理设置innodb_flush_log_at_trx_commit参数值,不要过度追求安全性 避免主键更新,因为这会带来大量的数据移动 NDBCluster 特性 […]

, , ,

接着上一篇 MySQL 数据库性能优化之索引优化,这是 MySQL数据库性能优化专题 系列的第四篇文章:MySQL 数据库性能优化之SQL优化 有人反馈之前几篇文章过于理论缺少实际操作细节,这篇文章就多一些可操作性的内容吧。 注:这篇文章是以 MySQL 为背景,很多内容同时适用于其他关系型数据库,需要有一些索引知识为基础 优化目标 减少 IO 次数 IO永远是数据库最容易瓶颈的地方,这是由数据库的职责所决定的,大部分数据库操作中超过90%的时间都是 IO 操作所占用的,减少 IO 次数是 SQL 优化中需要第一优先考虑,当然,也是收效最明显的优化手段。 降低 CPU 计算 除了 IO 瓶颈之外,SQL优化中需要考虑的就是 CPU 运算量的优化了。order by, group by,distinct … 都是消耗 CPU 的大户(这些操作基本上都是 CPU 处理内存中的数据比较运算)。当我们的 IO 优化做到一定阶段之后,降低 CPU 计算也就成为了我们 SQL 优化的重要目标 优化方法 改变 SQL 执行计划 明确了优化目标之后,我们需要确定达到我们目标的方法。对于 SQL 语句来说,达到上述2个目标的方法其实只有一个,那就是改变 SQL 的执行计划,让他尽量“少走弯路”,尽量通过各种“捷径”来找到我们需要的数据,以达到 “减少 IO […]

, ,

接着上一篇 MySQL 数据库性能优化之表结构,这是 MySQL数据库性能优化专题 系列的第三篇文章:MySQL 数据库性能优化之索引优化 大家都知道索引对于数据访问的性能有非常关键的作用,都知道索引可以提高数据访问效率。 为什么索引能提高数据访问性能?他会不会有“副作用”?是不是索引创建越多,性能就越好?到底该如何设计索引,才能最大限度的发挥其效能? 这篇文章主要是带着上面这几个问题来做一个简要的分析,同时排除了业务场景所带来的特殊性,请不要纠结业务场景的影响。 索引为什么能提高数据访问性能? 很多人只知道索引能够提高数据库的性能,但并不是特别了解其原理,其实我们可以用一个生活中的示例来理解。 我们让一位不太懂计算机的朋友去图书馆确认一本叫做《MySQL性能调优与架构设计》的书是否在藏,这样对他说:“请帮我借一本计算机类的数据库书籍,是属于 MySQL 数据库范畴的,叫做《MySQL性能调优与架构设计》”。朋友会根据所属类别,前往存放“计算机”书籍区域的书架,然后再寻找“数据库”类存放位置,再找到一堆讲述“MySQL”的书籍,最后可能发现目标在藏(也可能已经借出不在书架上)。 在这个过程中: “计算机”->“数据库”->“MySQL”->“在藏”->《MySQL性能调优与架构设计》其实就是一个“根据索引查找数据”的典型案例,“计算机”->“数据库”->“MySQL”->“在藏” 就是朋友查找书籍的索引。 假设没有这个索引,那查找这本书的过程会变成怎样呢?朋友只能从图书馆入口一个书架一个书架的“遍历”,直到找到《MySQL性能调优与架构设计》这本书为止。如果幸运,可能在第一个书架就找到。但如果不幸呢,那就惨了,可能要将整个图书馆所有的书架都找一遍才能找到我们想要的这本书。 注:这个例子中的“索引”是记录在朋友大脑中的,实际上,每个图书馆都会有一个非常全的实际存在的索引系统(大多位于入口显眼处),由很多个贴上了明显标签的小抽屉构成。这个索引系统中存放这非常齐全详尽的索引数据,标识出我们需要查找的“目标”在某个区域的某个书架上。而且每当有新的书籍入库,旧的书籍销毁以及书记信息修改,都需要对索引系统进行及时的修正。 下面我们通过上面这个生活中的小示例,来分析一下索引,看看能的出哪些结论? 索引有哪些“副作用”? 图书的变更(增,删,改)都需要修订索引,索引存在额外的维护成本 查找翻阅索引系统需要消耗时间,索引存在额外的访问成本 这个索引系统需要一个地方来存放,索引存在额外的空间成本 索引是不是越多越好? 如果我们的这个图书馆只是一个进出中转站,里面的新书进来后很快就会转发去其他图书馆而从这个馆藏中“清除”,那我们的索引就只会不断的修改,而很少会被用来查找图书 所以,对于类似于这样的存在非常大更新量的数据,索引的维护成本会非常高,如果其检索需求很少,而且对检索效率并没有非常高的要求的时候,我们并不建议创建索引,或者是尽量减少索引。 如果我们的书籍量少到只有几本或者就只有一个书架,索引并不会带来什么作用,甚至可能还会浪费一些查找索引所花费的时间。 所以,对于数据量极小到通过索引检索还不如直接遍历来得快的数据,也并不适合使用索引。 如果我们的图书馆只有一个10平方的面积,现在连放书架都已经非常拥挤,而且馆藏还在不断增加,我们还能考虑创建索引吗? 所以,当我们连存储基础数据的空间都捉襟见肘的时候,我们也应该尽量减少低效或者是去除索引。 索引该如何设计才高效? 如果我们仅仅只是这样告诉对方的:“帮我确认一本数据库类别的讲述 MySQL 的叫做《MySQL性能调优与架构设计》的书是否在藏”,结果又会如何呢?朋友只能一个大类区域一个大类区域的去寻找“数据库”类别,然后再找到 “MySQL”范畴,再看到我们所需是否在藏。由于我们少说了一个“计算机类”,朋友就必须到每一个大类去寻找。 所以,我们应该尽量让查找条件尽可能多的在索引中,尽可能通过索引完成所有过滤,回表只是取出额外的数据字段。 如果我们是这样说的:“帮我确认一本讲述 MySQL 的数据库范畴的计算机丛书,叫做《MySQL性能调优与架构设计》,看是否在藏”。如果这位朋友并不知道计算机是一个大类,也不知道数据库属于计算机大类,那这位朋友就悲剧了。首先他得遍历每个类别确认“MySQL”存在于哪些类别中,然后从包含 “MySQL” 书籍中再看有哪些是“数据库”范畴的(有可能部分是讲述PHP或者其他开发语言的),然后再排除非计算机类的(虽然可能并没有必要),然后才能确认。 所以,字段的顺序对组合索引效率有至关重要的作用,过滤效果越好的字段需要更靠前。 如果我们还有这样一个需求(虽然基本不可能):“帮我将图书馆中所有的计算机图书借来”。朋友如果通过索引来找,每次都到索引柜找到计算机书籍所在的区域,然后从书架上搬下一格(假设只能以一格为单位从书架上取下,类比数据库中以block/page为单位读取),取出第一本,然后再从索引柜找到计算机图书所在区域,再搬下一格,取出一本… 如此往复直至取完所有的书。如果他不通过索引来找又会怎样呢?他需要从地一个书架一直往后找,当找到计算机的书,搬下一格,取出所有计算机的书,再往后,直至所有书架全部看一遍。在这个过程中,如果计算机类书籍较多,通过索引来取所花费的时间很可能要大于直接遍历,因为不断往复的索引翻阅所消耗的时间会非常长。(延伸阅读:这里有一篇以前写的关于Oracle的文章,索引扫描还是全表扫描(Index Scan Or Full Table Scan)) 所以,当我们需要读取的数据量占整个数据量的比例较大抑或者说索引的过滤效果并不是太好的时候,使用索引并不一定优于全表扫描。 如果我们的朋友不知道“数据库”这个类别可以属于“计算机”这个大类,抑或者图书馆的索引系统中这两个类别属性并没有关联关系,又会怎样呢?也就是说,朋友得到的是2个独立的索引,一个是告知“计算机”这个大类所在的区域,一个是“数据库”这个小类所在的区域(很可能是多个区域),那么他只能二者选其一来搜索我的需求。即使朋友可以分别通过2个索引检索然后自己在脑中取交集再找,那这样的效率实际过程中也会比较低下。 所以,在实际使用过程中,一次数据访问一般只能利用到1个索引,这一点在索引创建过程中一定要注意,不是说一条SQL语句中Where子句里面每个条件都有索引能对应上就可以了。 看完这些分析,我想大家应该了解索引优化的一些基本思路了吧

, ,

接着上一篇 MySQL数据库性能优化之存储引擎选择,这是 MySQL数据库性能优化专题 系列的第六篇文章:MySQL数据库性能优化之硬件优化 在过往与很多人的交流过程中发现,在谈到基于硬件来进行数据库性能瓶颈分析的时候,常被大家误解为简单的使用更为强劲的主机或者存储来替换现有的设备。 个人觉得这其中可能存在一个非常大的误区。我们在谈论基于硬件进行优化的时候,不能仅仅将数据库使用的硬件划分为主机和存储两部分,而是需要进一步对硬件进行更细的分解,至少也应该分解到如下范畴: 主机 CPU:仅仅只能决定运算速度,及时是运算速度都还取决于与内存之间的总线带宽以及内存本身的速度 内存:大小决定了所能缓存的数据量,主要决定了热点数据的访问速度 磁盘: 大小:决定了你最终能存放多少数据量 转速:决定了你每一次IO请求的延时时间,也就是决定了我们常说的IOPS和MBPS 数目:磁盘数目决定了 类型 机械:SAS or SATA or FC ? SSD:磁盘 or PCI卡? Raid卡: 缓存:缓存大小对数据写入速度有较大影响,使用策略也会直接影响IO效率 电池:电池充放电策略会影响到瞬时IO的波动 其他:如总线带宽等,决定了CPU与内存间数据传输效率,这一点很多时候关注较少,但也可能会出现瓶颈 存储 内存:存储设备同样也有内存,用来存储前端主机访问的热点数据。存储的内存大小同样决定了热点数据的访问速度 磁盘:和主机磁盘类似 线路/环路带宽:环路带宽必须能够匹配磁盘带宽,至少不能少于磁盘所能输出的能力,否则就想被堵在高速收费站等待通行的车辆一样 网络 延时:不同的网络设备其延时会有差异,对于 OLTP 设备来说,延时自然是越小越好 吞吐量:对于数据库集群来说,各个节点之间的网络吞吐量可能直接决定集群的处理能力 iops:对于 OLTP 系统,数据传输更多是以小IO多并发方式,有时候光有大带宽并不一定能满足需求 硬件角度所能提供的处理能力,一定是上面所列的多个方面(这里仅仅只是主要部分,可能还有其他)共同决定的整体能力,任何一个方面出现瓶颈,都能导致整体性能上不去,也就是我们常说的木桶原理。 在以往的经验中,最容易出现性能瓶颈的地方主要会出现在以下几个方面: IO资源方面瓶颈 出现 IO 资源方面瓶颈的时候,主要表现在服务器 iowait 很高,usr 占比较少,系统响应较慢,数据库中经常会存在大量执行状态的 session。 遇到 IO 资源方面的瓶颈,我们可以使用的硬件层面优化方案主要就是: 增加内存加大可缓存的数据量:这个方案能否达到效果取决于系统热点数据的总量,毕竟内存的成本也是比较高的,而且单台设备所能管理的内存量也是有限的 改善底层存储设备的 IO […]

, , ,

接着上一篇 MySQL 数据库性能优化之缓存参数优化 ,这是 MySQL数据库性能优化专题 系列的第二篇文章:MySQL 数据库性能优化之表结构 很多人都将 数据库设计范式 作为数据库表结构设计“圣经”,认为只要按照这个范式需求设计,就能让设计出来的表结构足够优化,既能保证性能优异同时还能满足扩展性要求。殊不知,在N年前被奉为“圣经”的数据库设计3范式早就已经不完全适用了。这里我整理了一些比较常见的数据库表结构设计方面的优化技巧,希望对大家有用。 由于MySQL数据库是基于行(Row)存储的数据库,而数据库操作 IO 的时候是以 page(block)的方式,也就是说,如果我们每条记录所占用的空间量减小,就会使每个page中可存放的数据行数增大,那么每次 IO 可访问的行数也就增多了。反过来说,处理相同行数的数据,需要访问的 page 就会减少,也就是 IO 操作次数降低,直接提升性能。此外,由于我们的内存是有限的,增加每个page中存放的数据行数,就等于增加每个内存块的缓存数据量,同时还会提升内存换中数据命中的几率,也就是缓存命中率。 数据类型选择 数据库操作中最为耗时的操作就是 IO 处理,大部分数据库操作 90% 以上的时间都花在了 IO 读写上面。所以尽可能减少 IO 读写量,可以在很大程度上提高数据库操作的性能。 我们无法改变数据库中需要存储的数据,但是我们可以在这些数据的存储方式方面花一些心思。下面的这些关于字段类型的优化建议主要适用于记录条数较多,数据量较大的场景,因为精细化的数据类型设置可能带来维护成本的提高,过度优化也可能会带来其他的问题: 数字类型:非万不得已不要使用DOUBLE,不仅仅只是存储长度的问题,同时还会存在精确性的问题。同样,固定精度的小数,也不建议使用DECIMAL,建议乘以固定倍数转换成整数存储,可以大大节省存储空间,且不会带来任何附加维护成本。对于整数的存储,在数据量较大的情况下,建议区分开 TINYINT / INT / BIGINT 的选择,因为三者所占用的存储空间也有很大的差别,能确定不会使用负数的字段,建议添加unsigned定义。当然,如果数据量较小的数据库,也可以不用严格区分三个整数类型。 字符类型:非万不得已不要使用 TEXT 数据类型,其处理方式决定了他的性能要低于char或者是varchar类型的处理。定长字段,建议使用 CHAR 类型,不定长字段尽量使用 VARCHAR,且仅仅设定适当的最大长度,而不是非常随意的给一个很大的最大长度限定,因为不同的长度范围,MySQL也会有不一样的存储处理。 时间类型:尽量使用TIMESTAMP类型,因为其存储空间只需要 DATETIME 类型的一半。对于只需要精确到某一天的数据类型,建议使用DATE类型,因为他的存储空间只需要3个字节,比TIMESTAMP还少。不建议通过INT类型类存储一个unix timestamp 的值,因为这太不直观,会给维护带来不必要的麻烦,同时还不会带来任何好处。 ENUM & SET:对于状态字段,可以尝试使用 ENUM 来存放,因为可以极大的降低存储空间,而且即使需要增加新的类型,只要增加于末尾,修改结构也不需要重建表数据。如果是存放可预先定义的属性数据呢?可以尝试使用SET类型,即使存在多种属性,同样可以游刃有余,同时还可以节省不小的存储空间。 LOB类型:强烈反对在数据库中存放 LOB […]

, ,