InnoDB，5项优秀实践

InnoDB，5项优秀实践

MySQL是目前互联网公司使用最广的数据库，InnoDB是MySQL使用最广的存储引擎，MyISAM和InnoDB的五项最佳实践，和大家聊聊，尽量多讲“为什么”。

一、关于count(*)

知识点：MyISAM会直接存储总行数，InnoDB则不会，需要按行扫描。

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

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

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

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

uid PKage index

select count(*) where age<18 and sex='F';

查询未成年少女个数，两种存储引擎的处理方式类似，都需要进行索引扫描。

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

二、关于全文索引

知识点：MyISAM支持全文索引，InnoDB5.6之前不支持全文索引。

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

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

三、关于事务

知识点：MyISAM不支持事务，InnoDB支持事务。

画外音：Can't open file 'XXX.MYI'. 碰到过么?

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

四、关于外键

知识点：MyISAM不支持外键，InnoDB支持外键。

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

五、关于行锁与表锁

知识点：MyISAM只支持表锁，InnoDB可以支持行锁。

分析：

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

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

常见坑：

InnoDB的行锁是实现在索引上的，而不是锁在物理行记录上。潜台词是，如果访问没有命中索引，也无法使用行锁，将要退化为表锁。

画外音：***的行锁实现机制不同。

例如：

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最吸引人的地方。

戳这里，看该作者更多好文

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。