频繁插入,用什么存储引擎更合适?| 数据库系列

Posted 58沈剑

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了频繁插入,用什么存储引擎更合适?| 数据库系列相关的知识,希望对你有一定的参考价值。

有童鞋在后台留言:

沈老师,MyISAM只支持表锁,但网上文章却说,在并发插入量比较大的时候,比较适合使用MyISAM,这矛盾吗?

这个问题,涉及mysql表锁的一些细节,借着这个问题,系统性说下表锁的“所以然”。

画外音:网上不少文章只说结论,不说为什么,容易让人蒙圈。

MySQL表锁知识系统性梳理。

哪些存储引擎使用表锁?

MySQL,除InnoDB支持行锁外,MySQL的其他存储引擎均只使用表锁,例如:MyISAM, MEMORY, MERGE等。

表锁有什么好处?

(1)表锁占用内存少很多,行锁的数量与行记录数相关,非常耗内存;

(2)如果业务经常读写表中很大一部分数据时,表锁会更快,因为此时只涉及一个锁,而不是同时管理N多个锁;

(3)如果业务经常使用group by,表锁会更快,原因同(2);

画外音:这样的一些场景,使用MyISAM比InnoDB更优。

表锁是怎么运作的?

和其他临界资源的读写锁类似。

写时,要加写锁

(1)如果表没有锁,对表加写锁;

(2)否则,入写锁队列;

读时,要加读锁

(1)如果表没有写锁,对表加读锁;

(2)否则,入读锁队列;

表锁释放时

如果写锁队列和读锁队列里都有锁,写有更高的优先级,即写锁队列先出列。这么做的原因是,如果有“大查询”,可能会导致写锁被批量“饿死”,而写锁往往释放很快。

画外音:潜台词是,如果有大量并发update请求,select会等所有update请求执行完才执行。

如何查看表锁情况?

如果要分析表锁冲突情况,可查看:

Table_locks_immediate:立刻获得表锁的次数;

Table_locks_waited:需要等待表锁的次数;

这两个变量。

使用以下命令查看:

show status like 'Table%';

如果等待表锁的次数占比较大,说明表锁可能是潜在瓶颈。

说了半天,还是没有讲到点子上,为什么在并发插入量比较大的时候,比较适合使用MyISAM呢?不会因为表锁频繁冲突而导致吞吐量降低吗?

画外音:知识的系统性,比问题答案更重要。

知识点一:

MyISAM的索引与记录存储分离,有单独的区域存储行记录,PK是非聚集索引。

这个知识点就不展开了,以前讲过。

知识点二:

MyISAM表,如果数据文件(data file)紧密存储,中间没有空闲块(free blocks),数据总是插入到数据文件的尾部(end),就如同追加日志一样,性能很高,此时的并发insert与select是不加锁的(lock free)。

如上图所示:

(1)数据文件连续且紧密的存储着;

(2)并发insert无表锁争抢(只需插入队列互斥);

(3)insert只在数据文件的尾部进行;

(4)并发select也能够同时进行(共享读锁);

知识点三:

MyISAM表,如果数据文件(data file)中间有空洞(hole),上述机制会失效,直到空洞被新数据填满,又会启用不加锁机制。

空洞是怎么导致的?

删除或者修改数据,都可能导致空洞。

如上图所示:

(1)中间删除了一些数据,导致中间出现空闲块(free blocks);

(2)此时,select和insert会有表锁冲突,无法并发;

再如上图所示:

(1)随着插入的进行,中间的空闲块又被填满了;

(2)此时,并发select和insert又恢复了;

结论

虽然MyISAM只支持表锁,但高并发select与insert的业务场景,上述机制使得MyISAM的表锁依然有非常强劲的性能。

画外音:本文基于MySQL5.6。

思路比结论重要,希望大家有收获。

架构师之路-分享可落地的技术文章

近期文章

群聊比单聊,凭什么复杂这么多?

消息顺序性,究竟为什么这么难?

以上是关于频繁插入,用什么存储引擎更合适?| 数据库系列的主要内容,如果未能解决你的问题,请参考以下文章

频繁插入,用什么存储引擎更合适?| 数据库系列

如何系统性学习数据库知识? | 个人经验分享

如何系统性学习数据库知识? | 个人经验分享

有本MySQL的书,封面站了一只大鸟,你看过吗?

mysql 选择合适的存储引擎

Java技术-如何选择合适的MySQL存储引擎