Blogs/isky000

简朝阳

接前面一篇，这里再将之前在“中国系统架构师大会”5周年的时候发布的纪念册“IT架构实录”上的一篇文章发出来，也算是前面博文中PPT的一个文字版解读吧。 ——————————————————————————————- Oracle，MySQL 还是 NoSQL？前言随着阿里系的“去IOE”运动在社区的宣传声越来越大，国内正在掀起一股“去xxx”的技术潮。不仅仅是互联网企业，包括运营商以及金融机构都已经开始加入到这个潮流之中。作为运动中的这个“O”的Oracle数据库，自然就成为了众矢之的，众多CIO及CTO们都展示出一副欲除之而后快的表情。那在实际的应用场景中，我们到底该如何去选择数据的存取软件呢？大概在09到10年左右，突然一夜之间满世界都在谈论 NoSQL，到处是关系型数据库要被 NoSQL 替代的声音，几乎所有人都在鼓吹NoSQL的各种好，但到目前为止也没有看到哪个数据库软件的市场受到了NoSQL的大冲击，当初红极一时的Cassandra也从老东家 Facebook的最初应用场景中退出舞台而改用了HBase。当初从关系型数据库 MySQL 转投 NoSQL 怀抱的 Twitter 经历了各种“痛”之后，又回到了MySQL的怀抱… 作为一个架构师，面对如此众多选择的时候，到底该依据什么来作出正确的决定呢？下面是笔者经验中常用的3步决策思路，希望对大家稍有启发。一、系统对比  功能差异 Oracle无疑是功能最为全面一个，无论是用于OLTP场景还是OLAP场景，都有很好的技术手段支撑；MySQL作为开源数据库软件的代表，对于关系型数据库常用的功能也都全面覆盖到了，但作为 OLAP场景所不可或缺的 Hash Join这一特性确实给 MySQL 的 OLAP之路造成了较大阻碍；而各 NoSQL 产品大多都不能进行非 K/V 式的数据存取，能支持多维度条件过滤的产品选择较少。所以从功能角度来比较： Oracle > MySQL > NoSQL  性能强弱根据过去的一些测试及实际应用场景的经验，基于同等硬件资源，可以从以下3个角度来对比性能：  写入：由于 NoSQL 在数据存储及日志记录方面的架构及实现优化，相对 Oracle 及MySQL来说都有不小的优势。而 MySQL 和 Oracle 二者差异并不是特别大，暂且认为二者并列吧。所以从写入性能角度来比较：NoSQL > [...] [?]

Oracle MySQL Or NoSQL?

作为阿里引入 MySQL 数据库的第一批践行者之一，我经历了从Oracle的“一统天下”到被 MySQL 从周边应用逐步“蚕食”，直至核心系统都被替换成 MySQL的多个阶段。最初这是一个令人振奋的过程，虽然也伴随着DBA团队的不安，但总体都非常顺利。但随着这个过程的不断推进，痛苦慢慢袭来，尤其是对开发团队的影响越来越大。再后来…（再后来的事情就不便细说了）现在回过头来仔细思考，方向决策没有任何问题，但实际执行过程及执行策略还是存在不少可以商榷的地方。比如成本比较的核算方式，执行范围的一刀切等等。正是因为有这些“前因”，所以在2013年 OTN嘉年华上做了下面这样一个颇具争议的分享，针对目前吵得比较火热的“去IOE”中的“O”所涉及到的数据库领域的产品选择问题聊了下自己的看法。 Oracle my sql-or-nosql from Sky Jian 分享之后很多人都说还少了最后的一个收尾，那就是：到底什么系统该用 Oracle？什么系统该用 MySQL？什么系统该用 NoSQL？首先这个选择确实和业务场景有非常大的关系，其次有些背景让我不能把话说得太清楚了，最后就是还有想法我们可以线下随时沟通。作者： Sky.Jian 发布在：iSky000.com 欢迎订阅本站FeedCopyright © 2004-2012，可以任意转载, 但转载时务必以超链接形式标明文章原始出处和作者信息及版权声明链接：http://isky000.com/database/oracle-mysql-or-nosqlHosted On Dreamhost,折扣码 iMySQLer ) [?]

OOW2013@旧金山

从 OOW2013@旧金山回来半个月了，简单记录一下这次会议中 Oracle 的几个大事。 In-Memory Option：可以设置某些表的数据在内存中以列的方式再存放一份，用来解决OLTP与OLAP混用的场景下性能互扰的问题。列式数据存储的需求趋势越来越明显，SAP的HANA已经做的风生水起，Oracle也来凑热闹了，呵呵。实际的效果暂时还不得而知，期待正式场景下的效果反馈。 M6：Big Memory Machine 又一个大家伙，32TB 内存。虽然没有实际体验，但想想就觉得“可怕” Oracle正在软硬一体机的路线上坚定不移的向前迈进，M6的发布又是一次大跨步前进 M6 样机现场演示中： Database As Service Amazon 早在几年前就已经对外提供商业的在线关系型数据库服务了，国内的阿里云同样也提供了多种关系型数据库服务，现在这一阵营又将多出更为重量级的选手，Oracle正式宣布将进入这样一个市场，提供 Oracle 数据库在线服务。最后，还有这次OOW期间的另外一件大事就是美洲杯（America CUP）帆船赛， Oracle 代表的美国队来了次大逆转，在 1:8 落后的前提下居然连扳回8场最终9:8获胜，不知道是奇迹还是之前故意放水，哈哈。下面是借用eygle的一张图片，美洲杯颁奖礼上 Larry 手举奖杯额度镜头：作者： Sky.Jian 发布在：iSky000.com 欢迎订阅本站FeedCopyright © 2004-2012，可以任意转载, 但转载时务必以超链接形式标明文章原始出处和作者信息及版权声明链接：http://isky000.com/database/oow2013Hosted On Dreamhost,折扣码 iMySQLer ) [?]

Slides On OTN China Tour 2012

上周在北京参加了 OTN China Tour 2012（Oracle技术嘉年华）的活动，在会上有个简单的分享，主要是当 CPU 成为瓶颈的时候，我们改如何来优化数据库，分享的文档如下： MySQL Tuning For CPU Bottleneck from Sky Jian 作者： Sky.Jian 发布在：iSky000.com 欢迎订阅本站FeedCopyright © 2004-2012，可以任意转载, 但转载时务必以超链接形式标明文章原始出处和作者信息及版权声明链接：http://isky000.com/database/slides-on-otn-china-tour-2012Hosted On Dreamhost,折扣码 iMySQLer ) [?]

MySQL数据库性能优化之存储引擎选择

接着上一篇 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 数据库性能优化之SQL优化

接着上一篇 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”->“在藏” 就是朋友查找书籍的索引。假设没有这个索引，那查找这本书的过程会变成怎样呢？朋友只能从图书馆入口一个书架一个书架的“遍历”，直到找到《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数据库性能优化专题系列的第六篇文章：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数据库性能优化专题系列的第二篇文章：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 类型数据，虽然数据库提供了这样的功能，但这不是他所擅长的，我们更应该让合适的工具做他擅长的事情，才能将其发挥到极致。在数据库中存储 LOB 数据就像让一个多年前在学校学过一点Java的营销专业人员来写 Java 代码一样。字符编码字符集直接决定了数据在MySQL中的存储编码方式，由于同样的内容使用不同字符集表示所占用的空间大小会有较大的差异，所以通过使用合适的字符集，可以帮助我们尽可能减少数据量，进而减少IO操作次数。纯拉丁字符能表示的内容，没必要选择 latin1 之外的其他字符编码，因为这会节省大量的存储空间如果我们可以确定不需要存放多种语言，就没必要非得使用UTF8或者其他UNICODE字符类型，这回造成大量的存储空间浪费 MySQL的数据类型可以精确到字段，所以当我们需要大型数据库中存放多字节数据的时候，可以通过对不同表不同字段使用不同的数据类型来较大程度减小数据存储量，进而降低 IO 操作次数并提高缓存命中率适当拆分有些时候，我们可能会希望将一个完整的对象对应于一张数据库表，这对于应用程序开发来说是很有好的，但是有些时候可能会在性能上带来较大的问题。当我们的表中存在类似于 TEXT [...] [?]

MySQL 数据库性能优化之缓存参数优化

在平时被问及最多的问题就是关于 MySQL 数据库性能优化方面的问题，所以最近打算写一个MySQL数据库性能优化方面的系列文章，希望对初中级 MySQL DBA 以及其他对 MySQL 性能优化感兴趣的朋友们有所帮助。这是 MySQL数据库性能优化专题系列的第一篇文章：MySQL 数据库性能优化之缓存参数优化数据库属于 IO 密集型的应用程序，其主要职责就是数据的管理及存储工作。而我们知道，从内存中读取一个数据库的时间是微秒级别，而从一块普通硬盘上读取一个IO是在毫秒级别，二者相差3个数量级。所以，要优化数据库，首先第一步需要优化的就是 IO，尽可能将磁盘IO转化为内存IO。本文先从 MySQL 数据库IO相关参数（缓存参数）的角度来看看可以通过哪些参数进行IO优化： query_cache_size/query_cache_type （global） Query cache 作用于整个 MySQL Instance，主要用来缓存 MySQL 中的 ResultSet，也就是一条SQL语句执行的结果集，所以仅仅只能针对select语句。当我们打开了 Query Cache 功能，MySQL在接受到一条select语句的请求后，如果该语句满足Query Cache的要求（未显式说明不允许使用Query Cache，或者已经显式申明需要使用Query Cache），MySQL 会直接根据预先设定好的HASH算法将接受到的select语句以字符串方式进行hash，然后到Query Cache 中直接查找是否已经缓存。也就是说，如果已经在缓存中，该select请求就会直接将数据返回，从而省略了后面所有的步骤（如 SQL语句的解析，优化器优化以及向存储引擎请求数据等），极大的提高性能。当然，Query Cache 也有一个致命的缺陷，那就是当某个表的数据有任何任何变化，都会导致所有引用了该表的select语句在Query Cache 中的缓存数据失效。所以，当我们的数据变化非常频繁的情况下，使用Query Cache 可能会得不偿失。 Query Cache的使用需要多个参数配合，其中最为关键的是 query_cache_size 和 query_cache_type ，前者设置用于缓存 ResultSet 的内存大小，后者设置在何场景下使用 Query Cache。在以往的经验来看，如果不是用来缓存基本不变的数据的MySQL数据库，query_cache_size 一般 256MB 是一个比较合适的大小。当然，这可以通过计算Query Cache的命中率（Qcache_hits/(Qcache_hits+Qcache_inserts)*100)）来进行调整。query_cache_type可以设置为0(OFF)，1(ON)或者2(DEMOND)，分别表示完全不使用query cache，除显式要求不使用query cache（使用sql_no_cache）之外的所有的select都使用query cache，只有显示要求才使用query [...] [?]

更多>>>

Blogs/isky000

简朝阳

个人工具

名字空间

变换

查看

操作

搜索

导航

工具箱