我想知道为什么我需要在桌子上使用锁定模式页面。
最近我找到了一个非常好的案例，为什么不呢。当我试图在桌子上插入一行时，我遇到了僵局。经过大量的调查后，我发现我的表的锁定级别是Page，这是导致死锁的真正原因。
我的猜测是，这是大型高性能环境的常见情况，多个应用程序遇到相同的数据库
我唯一发现的是，如果我按照与分页相同的顺序处理行，我应该使用页面锁定。这看起来像一个很难满足的弱条件（特别是对于可能导致这种情况过时的缩放）。
我可以看到为什么人们会锁定一个完整的表或使用每行锁定，但页面锁定没有多大意义。或者是吗？
答案 0 :(得分：3)
您永远不会需要在桌面上使用LOCK MODE PAGE，但您可以选择这样做。
如果只有一行适合页面（或单行需要多个页面），它不会造成任何损害。
但是，如果您可以在页面上放置多行，则可以在LOCK MODE PAGE和LOCK MODE ROW之间进行有意义的选择。显然，如果你使用LOCK MODE ROW，那么一个进程锁定页面一行的事实不会阻止另一个进程在同一页面上的另一行上获得锁定，而LOCK MODE PAGE将防止这种情况。
LOCK MODE PAGE的优点是，当单个进程在单个事务中更新页面上的多行时，它需要较少的锁定。
所以，你必须做一个平衡的行为。你可以认为数据库中有这么多行，两个进程需要在同一页面上锁定不同行的可能性微不足道，并且使用LOCK MODE PAGE知道你的风险很小＆＃39 ;如果您使用LOCK MODE ROW，则会阻止其他进程无法阻止的进程。或者，您可以认为这种阻塞的风险是不可接受的，并且锁的数量增加不是问题，并且无论如何都决定使用LOCK MODE ROW。
历史上，当锁的数量是一个问题，因为内存不足（在大机器的主内存少于100 MiB的时候！），使用LOCK MODE PAGE保存锁定比现在更有意义当系统有几千兆字节的主存储器时。
请注意，如果两个进程想要更新同一行，则使用哪种锁定模式并不重要;一个人将获得一个锁并阻止另一个，直到事务提交（或者如果你没有使用显式事务，则直到语句完成）。
请注意，默认锁定模式仍然是LOCK MODE PAGE，主要是因为历史总是如此。但是，有一个ONCONFIG参数DEF_TABLE_LOCKMODE，您可以将其设置为row（而不是page），将默认表锁定模式设置为LOCK MODE ROW。您仍然可以在DDL语句中显式覆盖它，但如果您没有指定显式锁定模式，则默认值为row或page，具体取决于DEF_TABLE_LOCKMODE的设置。