【发布时间】：2023-03-16 01:08:02
【问题描述】：
对于我的客户，我偶尔会在他们的实时数据库中工作，以解决他们为自己创建的问题，或修复我的产品错误造成的不良数据。就像 Unix root 访问一样，这很危险。我应该提前学习哪些课程？
在对实时数据进行操作时要小心操作的第一件事是什么？
【问题讨论】：
标签： database
【发布时间】：2023-03-16 01:08:02
【问题描述】：
BEGIN TRANSACTION;
这样你可以在出错后回滚。
【讨论】：
-
是的，这几乎是防止面部疯狂的唯一方法。
-
@Graeme，您不应该在生产数据库上进行 DDL。您应该编写一个脚本，在您的测试数据库上运行它，在您的测试数据库通过 QA 后，您就可以在生产服务器上运行它。
-
@Paul：绝对。但有人可能会争辩说，无论是 DDL 还是 DML，您都应该对生产数据库进行任何类型的修改，在这种情况下，整个问题都是没有意义的。
-
Eduardo，到目前为止，它获得了 45 票，因为——大多数时候——你的冷汗在你的手指在键盘上完全向下移动之前就开始了——但是来不及停止手指。
-
也很有用，因为您可以在同一个事务中运行一堆选择以在提交之前验证结果 - 如果它们是意外的，不会造成任何伤害 - 只需回滚。
这些年来我学到了三件事……
首先，如果您要对实时数据进行更新或删除，请首先使用您将使用的 WHERE 子句编写一个 SELECT 查询。确保它有效。确保它是正确的。然后将 UPDATE/DELETE 语句添加到已知的工作 WHERE 子句。
你永远不想拥有
DELETE FROM Customers
坐在您的查询分析器中等待您编写 WHERE 子句...不小心点击了“执行”，而您刚刚杀死了您的 Customer 表。哎呀。
此外，根据您的平台，了解如何快速备份表格。在 SQL Server 2005 中，
SELECT *
INTO CustomerBackup200810032034
FROM Customer
会将整个 Customer 表中的每一行复制到一个名为 CustomerBackup200810032034 的新表中，然后您可以在完成更新并确保一切正常后将其删除。如果发生最坏的情况，从该表中恢复丢失的数据比尝试从磁盘或磁带恢复昨晚的备份要容易得多。
最后，小心级联删除删除您不打算删除的内容 - 在修改任何内容之前检查表的关系和键约束。
【讨论】：
-
你不是说从客户那里删除只是技术性的:-)
-
或者最好不要使用级联任何东西。
先做备份：无论如何，这应该是系统管理的第一法则
编辑：结合其他人所说的，确保您的更新有适当的 WHERE 子句。
理想情况下，永远不要更改实时数据库（除了插入和基本维护）。更改实时数据库的结构尤其充满了潜在的不良业力。
【讨论】：
对副本进行更改，当您满意时，将修复应用到实时版本。
【讨论】：
-
大多数情况下，复制数据库与实时不同，并非所有更改都与复制和实时相同。
-
如果副本数据库与实时数据库不同，那是否意味着它实际上不是副本数据库？ test/qa/copy 数据库的全部目的是在将更改应用于实时/生产数据库之前对其进行测试。
通常在执行 UPDATE 或 DELETE 之前，我会编写等效的 SELECT。
【讨论】：
-
作为一种快速简单的检查，我也喜欢这种方法。根据结果的数量，它可能不起作用，但至少它是 UPDATES 和 DELETES 的开始。
除非您在 BEGIN TRAN t1 中，否则切勿进行更新——不在开发数据库中，不在生产环境中，不在任何地方。永远不要在注释之外运行 COMMIT TRAN t1 -- 总是输入
--COMMIT TRAN t1
然后选择语句以运行它。 （显然，这仅适用于 GUI 查询客户端。）如果您执行这些操作，那么执行这些操作将成为第二天性，您几乎不会浪费任何时间。
我实际上有一个“更新”宏来输入这个。我总是把它粘贴进去来设置我的更新。您可以为删除和插入制作类似的。
begin tran t1
update
set
where
rollback tran t1
--commit tran t1
【讨论】：
-
是的，这正是我所做的。太多人说“不要忘记 where 子句”，但如果它错了怎么办？永远不要在没有这种开始/回滚/--提交模式的情况下更新实时数据库。
-
另一个改进是首先使用 where 子句执行“select * from”以确保它是正确的，然后使用相同的 where 子句运行更新。
-
Eric 是对的，尽管我将其排除在宏之外以避免范围蔓延。我有另一个宏输入“select * from”以供一般使用。
-
没有充分的理由不这样做。当我不得不在以前的工作中编写更新脚本时，我是这样做的，连同一个 SELECT before 更新和一个 SELECT after，所以我可以看到结果。运行了几次，看到结果正确，我把ROLLBACK改成了COMMIT。
始终确保您的 UPDATE 和 DELETE 具有正确的 WHERE 子句。
【讨论】：
-
是的，我以前就被这个烫伤了。
-
我也是。从那时起，我一直希望 SQL 的设计能够让 where 子句出现在第一位。
-
我一定会喜欢运行快速更新时那种下沉的感觉，它说“1279209394 条记录受到影响”。哦哦。 ;)
回答我自己的问题：
写更新语句时，乱写。
- 写信
UPDATE [table-name] - 写信
WHERE [conditions] - 回去写
SET [columns-and-values]
在说出要更改的值之前选择要更新的行比按其他顺序执行要安全得多。这使得update person set email = 'bob@bob.com' 不可能坐在您的查询窗口中，随时准备被错误的击键运行，准备弄乱表格中的每一行。
编辑：正如其他人所说，在编写 DELETE 之前为您的删除编写 WHERE 子句。
【讨论】：
例如，我这样创建 SQL
--Update P Set
--Select ID, Name as OldName,
Name='Jones'
From Person P
Where ID = 1000
我突出显示从末尾到 Select 的文本并运行该 SQL。一旦我确认它正在提取我想要更新的记录，我点击 shift-up 以突出显示 Update 语句并运行它。
请注意，我使用了别名。我从不明确更新表名。我总是使用别名。
如果我结合事务和回滚/提交来执行此操作，我真的非常安全。
【讨论】：
-
我也使用了选择检查——我已经通过这种方式发现了几个 where 子句错误。这是一个很好的完整性检查，尤其是当语句很复杂时。
-
这个方法是在看到我的主管在中午删除一个生产中的重要表后，在短时间内磨练出来的。
-
我切换选择并更新并删除选择上的 cmets。然后当我准备好时，我突出显示该区域并运行。也适用于删除。
小心使用实时数据库的#1 方法是什么？不要碰它。 :)
备份可以消除您对数据库造成的损害，但您仍然可能在这段时间内引入负面影响。
无论您认为您正在使用的脚本有多可靠，都要通过一个测试周期来运行它。即使“测试周期”意味着针对您自己的数据库实例运行脚本，请确保您这样做。在本地机器上引入缺陷比在生产环境中引入缺陷要好得多。
【讨论】：
- 检查、重新检查并再次检查任何正在更新的语句。即使您认为自己只是在进行简单的单列更新，迟早您会喝不到足够的咖啡并忘记“where”子句，从而破坏整个表。
我发现其他一些有用的东西：
如果使用 MySQL，请启用 Safe updates
如果您有 DBA，请让他们去做。
我发现这 3 件事使我没有造成任何严重伤害。
【讨论】：
-
是的，经典：UPDATE TABLE_NAME SET FIELD_X = 'whatever' [WHERE = missing]
- 没有人想要备份，但每个人都在呼唤恢复
- 使用外键引用创建数据库，因为您应该：
- 让自己尽可能地难以更新/删除数据并破坏结构完整性/其他东西
- 如果可能，请在必须先提交更改才能永久存储更改的系统上运行（即在修复数据库时停用自动提交）
- 尝试确定问题的类别，以便了解如何轻松解决问题
- 制定一个例行程序，将备份播放到数据库中，始终在测试服务器上准备第二个数据库，这样您就可以直接使用它了
- 因为请记住：如果某些事情完全失败，您需要尽快重新启动并运行
嗯，这就是我现在能想到的。采取大胆的段落，你会看到我的第一件事。 ;-)
【讨论】：
-
我想补充一下自动提交，因为它是一个重要的安全机制。如果您直接连接到数据库，通常可以在 db 连接参数中关闭自动提交。否则（db 前端产品），您可能需要寻找应用程序设置。
也许考虑不使用任何删除或删除。或者可能减少用户权限，以便只有特殊的数据库用户可以删除/删除东西。
【讨论】：
如果您使用的是 Oracle 或其他支持它的数据库，请在执行 COMMIT 之前验证您的更改。
【讨论】：
-
您必须小心，因为在您的交易未决期间记录可能会被锁定。
-
我通常使用 SQL developer for oracle，即使执行后它也不会自动提交。所以我们有一个预览然后提交。很酷的功能！
数据应始终通过脚本进行部署，以便在开发人员中正确执行所需的次数。当脚本有依赖数据可以在 dev 上正确运行时，适当地暂存它——如果你真的想小心的话，你不能逃脱这一步。
【讨论】：
检查两次，提交一次！
【讨论】：
开始前备份或转储数据库。
【讨论】：
要补充@Wayne 所说的内容，请在DELETE 或UPDATE 语句中的表名前写上您的WHERE。
【讨论】：
备份您的数据。定期与客户数据库打交道是一项艰巨的任务。
【讨论】：
始终添加 using 子句。
【讨论】：
我的规则（作为应用开发者）：不要碰它！这就是训练有素的 DBA 的用途。哎呀，我什至不想允许触摸它。 :)
【讨论】：
每个环境有不同的颜色：我们设置了我们的 PL\SQL 开发人员（适用于 Oracle 的 IDE），因此当您登录到生产数据库时，所有窗口都显示为鲜红色。有些甚至还为开发和测试分配了不同的颜色。
【讨论】：
确保在删除记录时指定 where 子句。
【讨论】：
始终首先在开发数据上测试除 select 之外的任何查询，以确保其产生正确的影响。
【讨论】：
- 如果可能，请与某人配对
- 在按 Enter 之前始终数到 3（如果是单独的，因为这会激怒你的搭档！）
【讨论】：
如果我使用脚本更新数据库，我总是确保在脚本的开头放置一个或两个断点，以防我意外运行/执行。
【讨论】：
我会在你的 UPDATE 之前添加 BEGIN TRAN 的建议，只是不要忘记实际执行 COMMIT；如果您将未提交的交易保持打开状态，您可能会造成同样多的损害。在更新过程中不要被电话、同事、午餐等分心，否则您会发现其他人都被锁定，直到您提交或回滚。
【讨论】：
在查询分析器中写出即席查询时，我总是注释掉任何破坏性查询（插入、更新、删除、删除、更改）。这样，运行它们的唯一方法是突出显示它们，而不选择注释部分，然后按 F5。
我还认为，如前所述，首先编写 where 语句，使用 select 并确保更改正确的数据是一个好主意。
【讨论】：
- 在更改之前始终备份。
- 始终通过脚本制作模组（例如 ALTER TABLE）。
- 始终通过存储过程修改数据（例如 DELETE）。
【讨论】：
创建一个只读用户（或让 DBA 来做）并只使用该用户查看数据库。为架构添加适当的权限，以便您可以查看存储过程/视图/触发器/等的内容。但没有能力改变它们。
【讨论】：