今天开始写数据库了。在第一篇文章中，讲讲MySQL最常用的两个存储引擎，MyISAM和InnoDB。根据自己的理解总结一些知识点，不仅是知识点，还有“为什么”。1、关于count(*)的知识点：MyISAM会直接存储总行数，InnoDB不会，需要按行扫描。潜台词是forselectcount(*)fromt;如果数据量很大，MyISAM会立即返回，而InnoDB会逐行扫描。做法：对于数据量较大的表，InnoDB不要轻易选择count(*)，这样会消耗大量的性能。常见陷阱：只有查询整张表的总行数时，MyISAM才会直接返回结果。当加上where条件时，两种存储引擎的处理方式是类似的。例如：t_user(uid,uname,age,sex);uidPKageindexselectcount(*)whereage<18andsex='F'查询未成年少女人数。两种存储引擎的处理方式类似，都需要进行索引扫描。启示：不管是什么存储引擎，都必须建立索引。2、关于全文索引知识点：MyISAM支持全文索引，InnoDB5.6不支持全文索引。做法：无论什么样的存储引擎，在数据量大、并发量大的情况下，都不要使用数据库自??带的全文索引，会造成少量请求占用大量的数据库资源。而是使用《索引外置》的架构设计方法。启示：对于大数据量、高并发的业务场景，MyISAM并不是全文索引的最佳选择。3、关于事务的知识点：MyISAM不支持事务，InnoDB支持事务。实践：事务是选择InnoDB的一个非常有吸引力的原因，它提供了提交、回滚和崩溃恢复等能力。当系统异常崩溃时，MyISAM有一定概率造成文件损坏，非常烦人。但是事务也是非常耗性能的，会影响吞吐量。建议只对一致性要求高的业务使用复杂事务。画外音：无法打开文件“XXX.MYI”。你遇到过吗？提示：MyISAM可以通过锁表锁实现类似事务的东西，但是对数据库性能影响很大，强烈不推荐。4、关于外键的知识点：MyISAM不支持外键，InnoDB支持外键。实践：不管是什么存储引擎，在数据量大、并发量大的时候都不要使用外键，建议应用保证完整性。5、关于行锁和表锁的知识点：MyISAM只支持表锁，而InnoDB可以支持行锁。分析：MyISAM：在执行读写SQL语句时，表会被锁住，所以当数据量大，并发量高时，性能会急剧下降。InnoDB：细粒度的行锁，在数据量大、并发量高的情况下性能优异。实践：网上经常说MyISAM是做select+insert业务的，因为MyISAM在文件末尾顺序添加记录的速度非常快。楼主的建议是大部分业务都是读写混合的。只要数据量大，并发量大，就应该用InnoDB。常见坑：InnoDB的行锁是在索引上实现的，而不是在物理行记录上。潜台词是，如果访问没有活动索引，行锁不能用，就会退化为表锁。画外音：Oracle的行锁实现机制不同。例如：t_user(uid,uname,age,sex)innodbuidPKnootherindexupdate_usersetage=10whereuid=1***索引，行锁。updatet_usersetage=10whereuid!=1卸载索引，表锁。updatet_usersetage=10wherename='shenjian没有索引，表锁。启示：InnoDB一定要建好索引，否则锁粒度大，会影响并发。综上所述，在大数据、高并发的互联网业务场景中，MyISAM和InnoDB具备条件，count(*)存储引擎性能相差无几，不使用全文索引，并且应该使用《索引外置》的设计方案来影响性能。只有在需要强一致性的时候，才使用不带外键的事务，应用的完整性由应用来保证。不能安装索引，InnoDB不能使用行锁。结语互联网业务场景，数据量大，并发度高，请使用InnoDB：锁对于提高并发性和数据一致性很有帮助。这两点是InnoDB最吸引人的地方。几个小知识点，希望大家有所收获。如果有不对的地方还请指正，一起讨论。【本文为专栏作者《58神剑》原创稿件，转载请联系原作者】点此阅读更多该作者好文
