【ChinaUnix社区站庆图书专题】MySQL之InnoDB存储引擎（获奖名单已公布2012-11-30）

zhaopingzi

没使用过，支持一下

crazyhadoop

1、InnoDB存储引擎和其他常用引擎有什么区别，您更偏爱哪一种，原因是什么？
答：InnoDB支持事务这是应用他的主要选择，相比之下，MyISAM查询和操作比较快，而且可以支持数据库文件拷贝，三个文件，拷走数据库就转移了。
看情况选择了，要是需要事务支持，Innodb妥妥的。
2、简述InnoDB存储引擎有哪些优点和缺点？
答：最大优点是支持事务，索引给力，支持行级锁，这样就不会查询锁表了，可以极高的提高查询效率。
缺点是：不支持全文类型的搜索(一般结合sphinx支持一下),更新索引比较慢，更新涉及的操作比较多，对硬盘读写的要求较高，对于不常更新的应用来说影响还不大Innodb不保存表的具体行数，这个比较坑爹。select count(*) from table 需要扫描全表
3、在使用InnoDB存储引擎的过程中你所遇到的困难和解决的方法。
答：
1.当一个innodb 的表里有一个auto_increment字段的时候，innodb在内存里保存一个计数器用来记录auto_increment的值，当插入一个新行数据时，就会用一个table lock来锁住这个计数器，直到插入操作完成。如果是一行一行的插入数据基本上没有什么问题，但是如果大量的并发插入就会因使效率很低，一般根据业务的特点选择配置一下innodb_autoinc_lock_mode，它是专门用来在使用auto_increment的情况下调整锁策略的，目前有三种选择：innodb_autoinc_lock_mode = 0 (“traditional” lock mode) innodb_autoinc_lock_mode = 1 (“consecutive” lock mode) innodb_autoinc_lock_mode = 2 (“interleaved” lock mode)。
2.主键占用空间有点大。更新比较慢，但是通过主键来访问数据效率是非常高的，在主键里，叶子节点存放的是表的实际数据，不仅仅包括主键字段的数据，还包括其他字段的数据，整个数据以主键值有序的排列。所以合理设置索引很有必要，

zhaopingzi

innodb存储引擎的存储是按照B+索引将主键作为键值进行聚集存储的，如果不指定主键，系统会隐藏建立一个主键。innodb存储引擎中所有的叶子节点为数据记录，并且数据记录逻辑上可以顺序访问。并且innodb存储引擎的数据存储和获取是按照页来进行的。因此，在查询时，会将整个页的数据加载到内存中，innodb存储引擎的默认页大小为16K。

frogoscar

好活动，要顶！

frogoscar

MyISAM 和 InnoDB 讲解

　　InnoDB和MyISAM是许多人在使用MySQL时最常用的两个表类型，这两个表类型各有优劣，视具体应用而定。基本的差别为：MyISAM类型不支持事务处理等高级处理，而InnoDB类型支持。MyISAM类型的表强调的是性能，其执行数度比InnoDB类型更快，但是不提供事务支持，而InnoDB提供事务支持已经外部键等高级数据库功能。

　　以下是一些细节和具体实现的差别：

　　◆1.InnoDB不支持FULLTEXT类型的索引。

　　◆2.InnoDB 中不保存表的具体行数，也就是说，执行select count(*) from table时，InnoDB要扫描一遍整个表来计算有多少行，但是MyISAM只要简单的读出保存好的行数即可。注意的是，当count(*)语句包含 where条件时，两种表的操作是一样的。

　　◆3.对于AUTO_INCREMENT类型的字段，InnoDB中必须包含只有该字段的索引，但是在MyISAM表中，可以和其他字段一起建立联合索引。

　　◆4.DELETE FROM table时，InnoDB不会重新建立表，而是一行一行的删除。

　　◆5.LOAD TABLE FROM MASTER操作对InnoDB是不起作用的，解决方法是首先把InnoDB表改成MyISAM表，导入数据后再改成InnoDB表，但是对于使用的额外的InnoDB特性(例如外键)的表不适用。

　　另外，InnoDB表的行锁也不是绝对的，假如在执行一个SQL语句时MySQL不能确定要扫描的范围，InnoDB表同样会锁全表，例如update table set num=1 where name like “%aaa%”

　　两种类型最主要的差别就是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左右。

chinafenghao

1、InnoDB存储引擎和其他常用引擎有什么区别，您更偏爱哪一种，原因是什么？
innodb是mysql下线阶段对事务支持最好的存储引擎。如果要在mysql下实施需要支持事务的项目，就像姜老说的，首选innodb。
innodb和其他引擎的区别就在于它支持事务，行锁，缓存索引和数据，外键支持等特性。

2、简述InnoDB存储引擎有哪些优点和缺点？
innodb和其他引擎的区别就在于它支持事务，行锁，缓存索引和数据，外键支持等特性

laputa73

学习了。
以前都是用默认引擎。
以后可以考虑分两个引擎使用。

crazyhadoop

回复 15# frogoscar


    读会锁表原因还是在于没有总行数的数据，只好锁表全读了

ruochen

前面大家说的，我就尽量少说了

1、InnoDB存储引擎和其他常用引擎有什么区别，您更偏爱哪一种，原因是什么？
InnoDB和MVCC 、ACID联系起来思考，其实现在的应用基本都使用InnoDB了，MyISAM已经比较少
对拷贝MYD需求，全文索引需求，以及原有的MyISAM没切换过的第三方应用（如某bbs系统）还是在用MyISAM的
MyISAM只是不太适宜delete和update比例比较高的应用场景，另外坏表的问题也很让人头痛

2、简述InnoDB存储引擎有哪些优点和缺点？
这个前面的同学回答的很多了

3、在使用InnoDB存储引擎的过程中你所遇到的困难和解决的方法。
估计是count(*)和ddl，建议曲线救国的思路来解决
count用基准+实时
ddl用第三方的osc思路或者ms切换


其实InnoDB能起来这么快，是随内存越来越便宜来推动的

hansion3406

佩服你，能发这么好的帖子，厉害