InnoDB,5 项最佳实践,知其所以然?

缓存讲了一个月《缓存架构,一篇足够》。今天,开始写数据库。

第一篇,说说 MySQL 两个最常用的存储引擎,MyISAM 和 InnoDB。照自己的理解,把一些知识点总结出来,不只说知识点,多讲“为什么”。

一、关于 count(*)
知识点:MyISAM 会直接存储总行数,InnoDB 则不会,需要按行扫描。

潜台词是,对于 select count(*) from t; 如果数据量大,MyISAM 会瞬间返回,而 InnoDB 则会一行行扫描。

实践:数据量大的表,InnoDB 不要轻易 select count(*),性能消耗极大。

常见坑:只有查询全表的总行数,MyISAM 才会直接返回结果,当加了 where 条件后,两种存储引擎的处理方式类似。

例如
t_user(uid, uname, age, sex);

  • uid PK

  • age index

select count(*) where age<18 and sex=‘F’;
查询未成年少女个数,两种存储引擎的处理方式类似,都需要进行索引扫描。

启示:不管哪种存储引擎,都要建立好索引。

二、关于全文索引
知识点:MyISAM 支持全文索引,InnoDB5.6 之前不支持全文索引。

实践:不管哪种存储引擎,在数据量大并发量大的情况下,都不应该使用数据库自带的全文索引,会导致小量请求占用大量数据库资源,而要使用《索引外置》的架构设计方法。

启示:大数据量 + 高并发量的业务场景,全文索引,MyISAM 也不是最优之选。

三、关于事务
知识点:MyISAM 不支持事务,InnoDB 支持事务。

实践:事务是选择 InnoDB 非常诱人的原因之一,它提供了 commit,rollback,崩溃修复等能力。在系统异常崩溃时,MyISAM 有一定几率造成文件损坏,这是非常烦的。但是,事务也非常耗性能,会影响吞吐量,建议只对一致性要求较高的业务使用复杂事务。
画外音:Can’t open file ‘XXX.MYI’. 碰到过么?

小技巧:MyISAM 可以通过 lock table 表锁,来实现类似于事务的东西,但对数据库性能影响较大,强烈不推荐使用。

四、关于外键
知识点:MyISAM 不支持外键,InnoDB 支持外键。

实践:不管哪种存储引擎,在数据量大并发量大的情况下,都不应该使用外键,而建议由应用程序保证完整性。

五、关于行锁与表锁
知识点:MyISAM 只支持表锁,InnoDB 可以支持行锁。

分析
MyISAM:执行读写 SQL 语句时,会对表加锁,所以数据量大,并发量高时,性能会急剧下降。
InnoDB:细粒度行锁,在数据量大,并发量高时,性能比较优异。

实践:网上常常说,select+insert 的业务用 MyISAM,因为 MyISAM 在文件尾部顺序增加记录速度极快。楼主的建议是,绝大部分业务是混合读写,只要数据量和并发量较大,一律使用 InnoDB。

常见坑
InnoDB 的行锁是实现在索引上的,而不是锁在物理行记录上。潜台词是,如果访问没有命中索引,也无法使用行锁,将要退化为表锁。
画外音:Oracle 的行锁实现机制不同。

例如
t_user(uid, uname, age, sex) innodb;

  • uid PK

  • 无其他索引

update t_user set age=10 where uid=1;
命中索引,行锁。

update t_user set age=10 where uid != 1;
未命中索引,表锁。

update t_user set age=10 where name=‘shenjian’;
无索引,表锁。

启示:InnoDB 务必建好索引,否则锁粒度较大,会影响并发。

总结
在大数据量,高并发量的互联网业务场景下,对于 MyISAM 和 InnoDB

  • 有 where 条件,count(*) 两个存储引擎性能差不多

  • 不要使用全文索引,应当使用《索引外置》的设计方案

  • 事务影响性能,强一致性要求才使用事务

  • 不用外键,由应用程序来保证完整性

  • 不命中索引,InnoDB 也不能用行锁

结论
在大数据量,高并发量的互联网业务场景下,请使用 InnoDB:

  • 行锁,对提高并发帮助很大

  • 事务,对数据一致性帮助很大

这两个点,是 InnoDB 最吸引人的地方。