问限制SQL Server Management Studio中更新/删除的行数

EN

不是的。

您有责任确保：

• 您的数据已正确备份，因此您可以在进行意外更改后还原您的数据。
• 您不是从头开始编写新查询并在没有首先测试它的情况下直接在生产数据库上执行它。
• 您在事务处理中执行查询，并在提交transaction.
• You之前复查更改知道如何正确过滤您的查询，以避免对整个表发出DELETE/UPDATE语句。如果有疑问，请始终先发出SELECT *或SELECT COUNT(*)-statement，以查看哪些记录将被保存。

不要依赖前端的一些愚蠢的功能，这些功能有时可能会拯救您，但在其他时间，这将完全毁了您。

很多好的评论已经说过了。只有一个小小的补充:我已经创建了一个解决方案，禁止在没有任何WHERE条件的情况下偶尔执行DELETE或UPDATE。这在我的名为SSMSBoost的外接程序中被实现为“致命操作守卫”。

(我的评论变得相当笨拙)

如果您不确定，一个简单的选择是BEGIN TRAN，执行更新，如果rows affected计数与预期的明显不同，执行ROLLBACK，否则，执行一些检查，例如SELECTs，以确保仅更新了预期的数据，然后执行COMMIT。这里需要注意的是，这将锁定行，直到您提交/回滚，并且如果更新了大量行，则可能需要升级到TABLOCK，因此您需要提前计划检查脚本。

也就是说，在任何半严肃的系统中，没有人，甚至是高级DBA，真的应该在prod DB (也可以说是正式的UAT DB )上执行直接的即席DML语句-这就是测试应用程序的目的(或者只有在考虑更改控制过程之后才执行的经过测试和验证的修补程序脚本)。

在不太正式的开发环境中，事情坏了真的很重要吗？事实上，如果你是Chaos Monkey的拥护者，从长远来看，让初级用户破坏你的数据可能是一件好事--这将确保你的流程重新编写脚本、迁移、静态数据部署、完整性检查都井然有序？