锁表后还能进行查询吗？这种情况下的查询操作是否可行？

呵... 本文共计2207个文字，预计阅读时间需要9分钟。

在日常的数据库运维中， 常常会碰到“锁表”这一情形：系统管理员或开发者主要原因是某些维护任务，对整张表加上了锁。很多人第一反应是：“那我是不是就只能等，连查询都做不了？”其实答案并非如此简单。让我们一起走进锁的世界，看看在锁表的背后还有哪些温暖的可能性，让业务继续呼吸，让数据依旧明亮。

一、 锁的种类：不同颜色的守护者

数据库里最常见的锁，大致可以分为两大类：

1️⃣ 共享锁

共享锁就像是一把透明的玻璃门，只要你不想推门进去改动，就可以轻轻推开查看。多个事务可以一边持有共享锁，这意味着它们都可以读取数据，但没有人能够修改。于是 即便整张表被共享锁覆盖，SELECT 查询仍然畅通无阻，绝绝子...。

2️⃣ 排他锁

官宣。 排他锁更像是一扇厚重的铁门，只允许唯一的事务进入并且对数据进行写操作。如果此时有其他事务尝试读取，它们只能在门外等候，除非该事务主动释放锁或者设置了超时。

了解了这两把钥匙后 我们就能判断：当表被共享锁时“查询还能跑”几乎是必然；而被排他锁时则要看具体场景和配置。

2️⃣ 锁粒度与查询能否穿透的细节

从“整张桌子”到“一颗螺丝钉”，数据库提供了多层次的锁粒度：，记住...

• 表级锁——一次性拦住整张桌子。
• 页级锁——拦住若干行所在的数据页。
• 行级锁

如果系统采用的是行级或页级细粒度的加锁， 即使某些行被占用，其他未被涉及的行依旧可以被读取。这就像是只把厨房的一扇抽屉上了链子，其他抽屉仍然自由打开。