接着上一篇 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
特性
分布式：分布式存储引擎，可以由多个NDBCluster存储引擎组成集群分别存放整体数据的一部分
支持事务：和Innodb一样，支持事务
可与mysqld不在一台主机：可以和mysqld分开存在于独立的主机上，然后通过网络和mysqld通信交互
内存需求量巨大：新版本索引以及被索引的数据必须存放在内存中，老版本所有数据和索引必须存在与内存中
适用场景
具有非常高的并发需求
对单个请求的响应并不是非常的critical
查询简单，过滤条件较为固定，每次请求数据量较少，又不希望自己进行水平Sharding
最佳实践
尽可能让查询简单，避免数据的跨节点传输
尽可能满足SQL节点的计算性能，大一点的集群SQL节点会明显多余Data节点
在各节点之间尽可能使用万兆网络环境互联，以减少数据在网络层传输过程中的延时
注：以上三个存储引擎是目前相对主流的存储引擎，还有其他类似如：Memory，Merge，CSV，Archive等存储引擎的使用场景都相对较少，这里就不一一分析了，如果有朋友感兴趣，后面再补充吧。
MySQL, MySQL数据库性能优化专题, performance tuning, storage engine
上周受邀于 IT168，在 2012年度的 DTCC 大会上做了一个小的主题分享，内容主要是最近几年在 MySQL 数据库的性能调优过程中积累的一点点经验总结，希望能对大家有用。
其中部分内容在之前的 第二届华东地区数据库大会 上已经有过分享，这次是在当时分享内容的基础上增加了硬件和系统层面的内容，同时根据听众反馈对原有内容进行了部分优化改进。
以下就是这次分享的 PPT 内容（有更新）：
MySQL性能调优最佳实践
View more presentations from Sky Jian
2012dtcc, MySQL, performance tuning
这个月11号应 蝎子 同学和 ThinkInLamp 的邀请，在上海光大会展中心参加了由 ThinkInLamp 社区组织的 第二届华东地区数据库大会，并做了一个题为“浅谈MySQL数据库优化”的主题分享交流。
考虑到参会人员大多是一线的技术工程师，而且还有很多是开发人员，所以内容更偏重于一些指导性的原则，会后将 PPT 格式稍作了调整，这里再发出来希望对感兴趣的朋友有所帮助。
浅谈 MySQL 性能调优
View more presentations from Sky Jian
MySQL, performance tuning
接着上一篇 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 次数” 和 “降低 CPU 计算” 的目标
常见误区
count(1)和count(primary_key) 优于 [...]
MySQL, MySQL数据库性能优化专题, performance tuning
接着上一篇 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数据库性能优化专题, performance tuning
