MySQL是目前互联网公司使用最广泛的数据库，InnoDB是MySQL使用最广泛的存储引擎，MyISAM和InnoDB的5个最佳实践，和你聊聊，试着说说“为什么”.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)innodb;uidPK没有其他索引update_usersetage=10whereuid=1；命中索引，行锁。update_usersetage=10whereuid!=1;缺少索引，表锁定。update_usersetage=10wherename='shenjian';没有索引，表锁。启示：InnoDB一定要建好索引，否则锁粒度大，会影响并发。综上所述，在大数据、高并发的互联网业务场景中，MyISAM和InnoDB都有条件，count(*)两个存储引擎的性能相差无几，不要使用全文索引，并且应该使用“外部索引”的设计方案事务影响性能，要求强一致性要求使用事务不带外键，保证完整性的应用不打索引，InnoDB不能使用行锁结论在互联网业务中数据量大、并发高的场景，请使用InnoDB：行锁对提高并发和数据一致性很有帮助。这两点是InnoDB最吸引人的地方。【本文为专栏作者《58神剑》原创稿件，转载请联系原作者】点此阅读更多该作者好文
