易栈网-膘叔

我知道INNODB不錯，但是我的VPS只有小小的512M內存，實在是扛不住，這玩意啥也不錯就吃掉了我不少內存了。於是我直接在my.cnf裏加上了skip-innodb。結果服務無法啟動。

找了一下資料 ，原來mysql 5.5以上的時候，默認的引擎就是innodB，因此，如果要skip掉它，必須告訴 mysql我的默認引擎是myisam。因此代碼就變成了這樣，在[mysqld]中加入：
default-storage-engine = MyISAM
然後再skip-innodb，接著運行service mysql restart，世界清靜 了。
原來運行top的時候，mysql一直佔有著70%左右的CPU。現在立刻清零。
一下子安逸了

MYISAM和INNODB的争论由来已久，如今，我又找到两篇文章，让我们看看有关这两种引擎的优劣的文章：浅谈MySQL存储引擎选择 InnoDB还是MyISAM以及InnoDB还是MyISAM 再谈MySQL存储引擎的选择

第一篇：浅谈MySQL存储引擎选择 InnoDB还是MyISAM

作者：酷壳，来源于：http://database.51cto.com/art/200905/122382.htm

MyISAM 是MySQL中默认的存储引擎，一般来说不是有太多人关心这个东西。决定使用什么样的存储引擎是一个很tricky的事情，但是还是值我们去研究一下，这里的文章只考虑 MyISAM 和InnoDB这两个，因为这两个是最常见的。

下面先让我们回答一些问题：
◆你的数据库有外键吗？
◆你需要事务支持吗？
◆你需要全文索引吗？
◆你经常使用什么样的查询模式？
◆你的数据有多大？

思考上面这些问题可以让你找到合适的方向，但那并不是绝对的。如果你需要事务处理或是外键，那么InnoDB 可能是比较好的方式。如果你需要全文索引，那么通常来说 MyISAM是好的选择，因为这是系统内建的，然而，我们其实并不会经常地去测试两百万行记录。所以，就算是慢一点，我们可以通过使用Sphinx从 InnoDB中获得全文索引。

数据的大小，是一个影响你选择什么样存储引擎的重要因素，大尺寸的数据集趋向于选择InnoDB方式，因为其支持事务处理和故障恢复。数据库的在小 决定了故障恢复的时间长短，InnoDB可以利用事务日志进行数据恢复，这会比较快。而MyISAM可能会需要几个小时甚至几天来干这些事，InnoDB 只需要几分钟。

您操作数据库表的习惯可能也会是一个对性能影响很大的因素。比如： COUNT() 在 MyISAM 表中会非常快，而在InnoDB 表下可能会很痛苦。而主键查询则在InnoDB下会相当相当的快，但需要小心的是如果我们的主键太长了也会导致性能问题。大批的inserts 语句在MyISAM下会快一些，但是updates 在InnoDB 下会更快一些——尤其在并发量大的时候。

所以，到底你检使用哪一个呢？根据经验来看，如果是一些小型的应用或项目，那么MyISAM 也许会更适合。当然，在大型的环境下使用MyISAM 也会有很大成功的时候，但却不总是这样的。如果你正在计划使用一个超大数据量的项目，而且需要事务处理或外键支持，那么你真的应该直接使用InnoDB方 式。但需要记住InnoDB 的表需要更多的内存和存储，转换100GB 的MyISAM 表到InnoDB 表可能会让你有非常坏的体验。

第二篇：InnoDB还是MyISAM 再谈MySQL存储引擎的选择

作者：邵宗文，来源于：http://database.51cto.com/art/200905/124370.htm

两种类型最主要的差别就是Innodb 支持事务处理与外键和行级锁.而MyISAM不支持.所以MyISAM往往就容易被人认为只适合在小项目中使用。

我作为使用MySQL的用户角度出发，Innodb和MyISAM都是比较喜欢的，但是从我目前运维的数据库平台要达到需求：99.9%的稳定性，方便的扩展性和高可用性来说的话，MyISAM绝对是我的首选。

原因如下：

1、首先我目前平台上承载的大部分项目是读多写少的项目，而MyISAM的读性能是比Innodb强不少的。

2、MyISAM的索引和数据是分开的，并且索引是有压缩的，内存使用率就对应提高了不少。能加载更多索引，而Innodb是索引和数据是紧密捆绑的，没有使用压缩从而会造成Innodb比MyISAM体积庞大不小。

3、从平台角度来说，经常隔1，2个月就会发生应用开发人员不小心update一个表where写的范围不对，导致这个表没法正常用了，这个时候 MyISAM的优越性就体现出来了，随便从当天拷贝的压缩包取出对应表的文件，随便放到一个数据库目录下，然后dump成sql再导回到主库，并把对应的 binlog补上。如果是Innodb，恐怕不可能有这么快速度，别和我说让Innodb定期用导出xxx.sql机制备份，因为我平台上最小的一个数据 库实例的数据量基本都是几十G大小。

4、从我接触的应用逻辑来说，select count(*) 和order by 是最频繁的，大概能占了整个sql总语句的60%以上的操作，而这种操作Innodb其实也是会锁表的，很多人以为Innodb是行级锁，那个只是 where对它主键是有效，非主键的都会锁全表的。

5、还有就是经常有很多应用部门需要我给他们定期某些表的数据，MyISAM的话很方便，只要发给他们对应那表的frm.MYD,MYI的文件，让 他们自己在对应版本的数据库启动就行，而Innodb就需要导出xxx.sql了，因为光给别人文件，受字典数据文件的影响，对方是无法使用的。

6、如果和MyISAM比insert写操作的话，Innodb还达不到MyISAM的写性能，如果是针对基于索引的update操作，虽然MyISAM可能会逊色Innodb,但是那么高并发的写，从库能否追的上也是一个问题，还不如通过多实例分库分表架构来解决。

7、如果是用MyISAM的话，merge引擎可以大大加快应用部门的开发速度，他们只要对这个merge表做一些select count(*)操作，非常适合大项目总量约几亿的rows某一类型(如日志，调查统计)的业务表。

当然Innodb也不是绝对不用，用事务的项目如模拟炒股项目，我就是用Innodb的，活跃用户20多万时候，也是很轻松应付了，因此我个人也是很喜欢Innodb的，只是如果从数据库平台应用出发，我还是会首选MyISAM。

另外，可能有人会说你MyISAM无法抗太多写操作，但是我可以通过架构来弥补，说个我现有用的数据库平台容量：主从数据总量在几百T以上，每天十 多亿 pv的动态页面，还有几个大项目是通过数据接口方式调用未算进pv总数，(其中包括一个大项目因为初期memcached没部署,导致单台数据库每天处理 9千万的查询)。而我的整体数据库服务器平均负载都在0.5-1左右。

文章都不太长，适合着看看就行了。。

innodb和myisam两种类型的表，是mysql的基础表。很多人为了选择该使用哪 种表而头疼。
一般来说innodb对事务的支持比较好，而myisam则一般，innodb是行锁,mysql是表锁。但。。。下面这个测试却：
原文：http://rdc.taobao.com/blog/dba/html/295_insert_benchmark_for_myisam_and_innodb.html
作者：陶方
内容：

--EOF--
对于这个图是什么生成的，我也很有兴趣。。。。目前未知

myisam如果经常insert,update,delete会产生很多的碎片，而且因为表类型的关系，其实它如果使用不当，也会有损坏的情况发生，一般情况下，可以使用repair table来进行修复。老王说，尽量使用 myisamchk来进行修复，因为这是命令行下的，所以，我没有用过。命令行下，我用的也是repair table。
所以，我转载了老王的这篇博客，写完后，老王又来了一篇TableCache设置过小造成MyISAM频繁损坏，看来，myisam表之所以容易损坏，和tablecache的设置还是有关的。

修复表的原文如下：
当我们用PHPMyAdmin浏览数据库时，有时候会发现某些MyISAM表的Collation项显示为“in use”，这多半说明此表已经损坏。即便是没有出现“in use”字样，也不能就此说明表是完好无损的，熟悉检查及修复方法是必须的。

通过语句：

检查表使用CHECK TABLE语句，如下：

CHECK TABLE tbl_name [, tbl_name] ... [option] ...
option = {FOR UPGRADE | QUICK | FAST | MEDIUM | EXTENDED | CHANGED}

修复表使用REPAIR TABLE语句，如下：

REPAIR [NO_WRITE_TO_BINLOG | LOCAL] TABLE
    tbl_name [, tbl_name] ...
    [QUICK] [EXTENDED] [USE_FRM]

通过命令：

检查修复表可以使用myisamchk命令：

myisamchk [options] tbl_name ...

如果没有指定参数，那么myisamchk命令缺省执行的就是检查动作。若是要修复表，可以使用-r或-o参数，应该优先使用-r修复，不行的话再使用-o修复。此外，在修复前应该使用FLUSH TABLES刷新缓存，并关闭数据库服务器或者锁定所有的待修复表，以确保在修复过程中不会有其他写操作。

自动修复：

在my.cnf配置文件中的mysqld部分设定myisam-recover参数，当服务启动时可以自动修复有问题的表（速度快慢视数据多少）：

[mysqld]
myisam-recover [= options]

参数有DEFAULT，BACKUP，FORCE，QUICK，可以设定为BACKUP,FORCE，万万不可单独设置成FORCE，否则数据文件丢了都没处哭去。


应该尽量使用myisamchk命令去修复，不行再用repair语句去修复（慢），还不行就参考下面链接。

参考文档：How to Repair Tables
而对于tablecache的设定，老王建议：如果你比较懒惰，也可以用MySQL Performance Tuning Primer Script来判断参数是否合理

问题：主从服务器表类型的选择

一般的共识是主服务器使用innodb，从服务器使用myisam，以便各尽其能。

问题：主从服务器字段类型的选择

字段类型对于分页等操作有很大影响。主服务器一般是innodb，因为不涉及查询，所以可以使用varchar等来存储字符串来节省空间，从服务器一般是 myisam，因为涉及查询，所以必须在char和varchar之间仔细权衡，没有varchar, text, blob字段的表是静态表，反之是动态表，静态表的检索效率要比动态表好若干倍，一般来说，所有涉及大结果集的查询都应该尽可能保证在静态表上完成，这里 说一个例子：比如说常见的articles表有title(varchar), body(text)等字段，在做文章列表的时候，因为不是静态表，所以查询不会很快，下面开始重构解决方案：把原来的articles表拆分成 subjects表和contents表，title字段设置为一个足够的char类型放在subjects表里，body字段还保持是text类型放到 contents表里，subjects和contents表之间的关系是一对多，这样，顺带着也方便的实现了多页文章的功能，而且更重要的是在查询文章 列表的时候，操作都是在subjects静态表里完成，效率肯定会比前一种方案提升很多。

问题：主从服务器NOW()函数造成数据不一致

假设在主服务器上执行一条INSERT .... VALUES ( ..., NOW())，那么在从服务器上也会同样执行一条的SQL语句，但是一来主从服务器各自的时间设置可能就不一致，二来主从服务器间的SQL同步也可能存在 时间上的的延迟，这样，NOW()在两台服务器上的结果就可能不一致。解决方法是显而易见的，就是不要使用NOW()，时间的计算在应用程序里完成。这里 介绍一个额外的小技巧：在PHP里如果想获得当前时间的时间戳，不要用time()，而应该使用$_SERVER[‘REQUEST_TIME’] （PHP版本大于5.1有效），这样少做了一次系统调用，更有效率。

问题：主从服务器读写分离时读操作失败

先重现一下问题：比如说添加一条新数据，添加成功后根据last_insert_id跳转到新添加数据的浏览页面。在此过程中添加新数据的操作是在主服务 器上完成的，浏览新数据的操作实在从服务器上完成的，不过由于主从服务器间SQL同步存在延迟，所以当使用last_insert_id在从服务器上查询 的时候，从服务器很可能还没有还没来得及同步到此记录，所以读操作失败。解决思路也不复杂，在代码里加入一个缓存层（可以使用memcached），新添 加的数据都顺手放到缓存层里一份，新数据的读操作也先查询缓存层，这样就不会再有读操作失败的问题了，当然删除或者更新数据的时候也要顺带着处理好缓存数 据，可以使用观察者模式来搞定。不过这样缓存方案只限于读取单一的记录，对于读取列表的记录的情况，则是无效的。

问题：主从服务器索引是否有必要保持一致

一般都是利用主从服务器完成读写分离，从服务器上进行读操作，主服务器进行写操作，这样的话，主服务器上仅保留主键，外键，唯一索引等必要的索引即可，以 便保持数据合法性，而对于那些原本用于优化SELECT操作的索引，可以全部删除，如此的话主服务器的写操作效率会提升很多。

作者：老王
原文：http://hi.baidu.com/thinkinginlamp/blog/item/5d72dd5469b1885fd0090633.html