MySQL表锁,总以为自己懂了

·  阅读 1830

关于 MySQL 的如下问题,你能准确的答出来么?

(1)和行锁相比,表锁有什么优势?

(2)频繁 group by 的业务,用 MyISAM 更好,还是 InnoDB 更好,为什么?

(3)某个 session 占有了表写锁,有另外 N 个 session 又要对表进行写操作,MySQL 是如何处理的?

(4)某个 session 释放了表写锁,有另外 N 个 session 要对表进行写操作,同时还有 M 个 session 要对表进行读操作,谁先抢到锁,为什么?

(5)如何判断表锁是不是主要冲突点?

(6)如何高效的实现并发插入与查询,如何互斥?

(7)MyISAM 什么情况下,数据文件会出现空洞?

(8)MyISAM,假如数据文件有空洞,新插入的数据是先补上空洞,还是插入在文件尾部?

但如果你花 1 分钟认真阅读了《频繁插入 (insert) 的业务,用什么存储引擎更合适?》,上述问题都是小 case。

_画外音:_可以跳回原文去找答案。

从评论留言来看,不少同学的反馈是:

“… 文章太容易了…”

“…MyISAM 过时了…”

听了大家的反馈,我起初是抱歉,以为聊了一个大家都非常清楚的话题,浪费了大家的时间。

可是,从作业题的评论情况来看:

竟然没有一个同学答对!!!

画外音:可以跳回原文去看评论,很遗憾一个 offer 都发不出去。

当然,可能会有朋友说,你乱出题,你的答案靠谱么。这样,这次我直接贴 MySQL 官网的截图吧:

通常情况下,下列四种情况,表锁会优于行锁:

这些情况,用更粗粒度的锁,更易于应用程序调优,因为锁开销会比行锁更小。

画外音:英文不好,翻译不对的大家提出。

很多时候,我们以为自己懂了,其实懂的不透彻。

很多时候,思路比结论重要,MyISAM 确实现在不是主流,但其中的技术思路,也值得我们学习。

架构师之路 - 分享技术思路

大家看下开篇的 8 个问题,以及作业题,重温下《频繁插入 (insert) 的业务,用什么存储引擎更合适?》,相信你会有新的收获。

调研:

开篇的 8 个题,全有把握答对的同学,扣个 1。

分类:
后端
标签: