Question

事故中一个简单的愚蠢“UPDATE table SET something=another WHERE (always true)”很容易破坏数据库中的所有内容。它可能是人为错误，SQL注入/溢出/截断攻击，或构成WHERE原因的代码中的错误。

流行数据库是否提供了一种保护表的功能，限制最大行数可以在一个SQL语句中更新？

我的意思是某种防御性设置适用于数据库上的表前访问权限：无法绕过，编程代码少，没有人为错误（除非授予自己太多访问权限）。

Answer 1

您可以添加一个触发器来检查正在更新的行数（计算插入的魔术触发器表），以及RAISEERROR（如果行数过多）。

Answer 2

我什么都不知道。

我不确定这会解决任何问题。数据库如何区分SQL注入攻击和碰巧超出限制的每晚批量更新？

一个假设是自动提交设置为true。如果未提交SQL注入攻击，您总是有机会将其回滚，假设您正在查看日志等。

我认为真正的答案是更好地分层应用，验证，绑定等。如果这些措施到位，你就无法进行SQL注入。

Answer 3

简短的回答是“不”......

Oracle允许您设置可以分配给用户的define profiles，以限制CPU，逻辑读取等资源的使用。但是，它不是为了您的目的，而是为了在多用户环境中管理资源。

也许更重要的是，它也有flashback table，因此可以轻松撤消意外更改。

大部分场景应该通过其他方式处理：

人为错误：大多数用户不应被授予对表的更新权限，应强制他们调用API（通常通过应用程序）来执行更新。访问实时数据库时，DBA必须非常小心 - 不要介意行限制，他们可以完全放弃表格！
注射攻击：这些可以而且应该防止发生
代码错误：这些应该通过适当的测试来捕获

如果您的数据很重要，则应该对其进行适当的保护并按照上述方式进行处理，并且不需要最大行更新限制;如果您的数据不足以保护，如上所述，那么为什么要担心？

Answer 4

正如David B首先指出的那样，你可以用触发器做到这一点。无论如何，使用@@ ROWCOUNT测试启动触发器是一个很好的做法。想象一下：

CREATE TRIGGER dbo.trg_myTrigger_UD ON dbo.myTable FOR UPDATE, DELETE
AS
IF @@ROWCOUNT <> 1 RETURN

这会触发任何试图影响多行的更新和/或删除。

作为一般规则，我使用＆lt;＆gt;的行数测试开始我的0.关键是如果触发器被实际影响没有行的东西拉开（UPDATE表SET col1 ='hey'WHERES 1 = 0）那么在运行触发器代码时没有意义，因为它无论如何都不会做任何事情。

Answer 5

我理解你的理由，但是你想如何处理合法的批次？

如果您做了一些更改，并且希望能够“撤消”更改，请使用事务。如果您希望能够重新构建数据，请使用更改存档。但是，您无法仅从具有100％正确结果的批次创建“这是正确/不正确的批次”检查。

Answer 6

您只需编写存储过程并仅向用户公开。在正常情况下，您不会在特权账户中工作。只在需要时以管理员身份连接。

Answer 7

您可以在事务中包装更新并在提交之前提示用户（让他们知道要更新的行数）。