MySQL表锁，以为自己懂了，结果一个答对的都没有！！！

关于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。