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最吸引人的地方。 几个小的知识点,希望大家有收获。有说的不对的,欢迎大家指正,共同讨论。谢转。

本文分享自微信公众号 - 架构师之路(road5858)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2018-08-08

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Hadoop实操

如何在Impala中实现拉链表

拉链表是针对数据仓库设计中表存储数据的方式而定义的,即是记录历史。记录一个事物从开始,一直到当前状态的所有变化的信息。传统数据仓库一般采用拉链的方式保留主数据(...

1.4K100
来自专栏杨建荣的学习笔记

分区表的一个持续改进方案(r9笔记第53天)

今天看到一个同事发了一封邮件,是关于分区的,他说目前某个表的分区需要添加,为了保险起见,让我先添加三年的。这里折射出几个问题。 1.如果没有这位开发同学提醒,我...

32140
来自专栏大愚Talk

MySQL InnoDB引擎锁的总结

我们开的的各式各样系统中,系统运行需要CPU、内存、I/O、磁盘等等资源。但除了硬资源外,还有最为重要的软资源:数据。

28030
来自专栏数据和云

郑保卫 - 索引优化策略及实战

本文中将要介绍的索引战略方案是以尽可能少的索引来满足尽可能多的数据读取类型的索引构建方法。这个策略方案要求在构建索引时,尽可能多地搜集当前正在使用的未来将要出...

34550
来自专栏杨建荣的学习笔记

MySQL中explain的几点用法

MySQL里的explain命令内容还是很丰富的,值得好好的挖掘出不少东西来。 本身来说explain就是生成执行计划的内容,如果细看,这个内容和Orac...

36570
来自专栏数据和云

解锁不可见索引新特性,处理ORA-01555故障

何国亮 云和恩墨交付部技术顾问,获得 Oracle 11g OCM 认证。有超过 6 年超大型数据库专业服务经验,曾为通信运营商、银行、保险、政府、制造业...

14250
来自专栏杨建荣的学习笔记

MYSQL索引条件下推的简单测试

自MySQL 5.6开始,在索引方面有了一些改进,比如索引条件下推(Index condition pushdown,ICP),严格来说属于优化器层面的改进。 ...

40750
来自专栏数据和云

走在专家的路上,每天优化一条SQL

前段时间我们分享过一篇文章,巧用复合索引,有效降低系统IO,围绕B*Tree索引的使用,解读了如何合理地使用索引,尤其是复合索引,以及通过正确的索引类型来提高性...

30660
来自专栏性能与架构

Mysql 5.7 的‘虚拟列’是做什么?

Mysql 5.7 中推出了一个非常实用的功能 虚拟列 Generated (Virtual) Columns 对于它的用途,我们通过一个场景来说明 假设有一...

42960
来自专栏逸鹏说道

维护索引(4)——通过重组索引提高性能

前言: 如果碎片程度小于30%,建议使用重组而不是重建。因为重组不会锁住数据页或者数据表,并且降低CPU的资源。 总得来说,重组会清空当前的B-TREE,特别是...

26980

扫码关注云+社区

领取腾讯云代金券