【程序员搞笑图片】有时

248 条评论 | |

你也许感兴趣的：

共有 248 条讨论

  1. 至少执行一次选择查询，检查您的搜索是否有效

    回复

    1. 这是我以前的非技术老板经常说的一句话（他最初白手起家，靠一本冷核熔的书创办了一家公司，笑）。多么伟大的人啊

      回复

      1. 在 Macromedia 收购 Allaire 的那一年，我参加了 Macromedia 用户大会。那是一段多么令人神往的时光啊。我记得，ColdFusion 用户群对这次收购非常兴奋。你上一次听说一家小公司开发的工具被一家大公司收购，而且每个人都兴奋不已是什么时候的事了。我相信，Macromedia 当时深受用户喜爱也是一个原因。疯狂的时代

        回复

        1. 是啊，这勾起了我很多回忆！即使在我们的 “2.0 ”软件中，也有一些 ColdFusion 页面。随着 nuxt/vue/vuetify 的逐步淘汰，我们的软件也有了光鲜亮丽的应用程序外观。

          如果孩子们知道这些进步就好了！

          回复

      2. 他不是非技术人员，只是因为他没有计算机科学学位，他创办了一家 IT 公司。

        回复

        2. 他给我讲了他的出身故事（在加入公司之前就认识他和公司，他是朋友的朋友），他是一个行业里非常聪明、为人和善的人。他是我在工作内外真正了解并深深尊敬的少数几个人之一。

          他看到了这个细分市场和机会，当时就通过书本学习如何编码，并在业余时间学习编码，反复编写程序。

          不过，请继续吧，你显然比我更了解我的老板，笑死我了。

          回复

          1. 不，那家伙是在说他是个技术人员，即使他没有学位。

            回复
      1. BEGIN;
DO THE THING;
SELECT THE THING;
ROLLBACK;

        你还能怎么测试更新/删除？

        回复

        1. 有人知道为什么会出现磁盘/CPU 峰值，导致大量用户查询跳转吗？

          回复

      2. 我总是两个都做。不能太确定。

        回复

      3. 当你的事务开始阻塞其他会话，而你是阻塞树的头阻塞者，影响到每个用户，让每个人都怀疑ERP/WMS/CRM 系统已经停止运行时，这样做也会很糟糕。理想情况下，你应该复制到一个测试环境并在那里进行测试。我喜欢这样做：

        SELECT * --DELETE
FROM SomeTable
WHERE SuchAndSuch=Something AND SomethingElse=SomeOtherThing

        Or

        SELECT * --UPDATE SomeTable SET SomeColumn=SomeValue
FROM SomeTable
WHERE SuchAndSuch=Something AND SomethingElse=SomeOtherThing

        从 SELECT 得到想要的结果后，只需从 DELETE 或 UPDATE 开始高亮显示，而不使用 — 就可以了（除非触发器或其他诡计发挥作用，但无论采用哪种方法都要考虑这一点）。

        不，我从来没有遇到过这种情况。）

        回复

        1. 你说得一点都没错，我也经历过这种情况。不过，我认为会话受阻并没有数据丢失那么糟糕。

          回复

    4. 在 SSMS 中，你也可以把这个问题搞砸。编写更新，选择更新部分并用热键注释，编写选择，运行，选择选择并用热键注释，选择更新，用热键取消注释，但不要取消选择行，然后运行。

      现在，你的更新刚刚运行，但却没有写 “哪里”，因为某位天才说：”嘿，你知道什么是超酷和预期的行为吗？只需选择输入的部分内容就能运行，这是其他功能所不具备的”。真聪明！

      总之，我就是这样在没有备份的地方抹掉了多年的数据。那天我学到了很多关于事务和备份的知识。

      从那以后，我一直在有效地使用这项功能，但至少在第一次使用时需要弹出警告。

      回复

      1. 我一直使用的一个简单解决方案是：只使用表别名编写 UPDATE 语句。

        这样，只运行更新行就会失败，因为不存在使用别名的表。

        举例说明

        UPDATE p SET Price = 0 -- this line fails when run independently
-- SELECT *
FROM Products p
WHERE ProductId = 69

        在任何非开发环境中（有时也包括开发环境），我都会将其与自动回滚（直到验证）的事务结合起来。

        编辑：十年前，我就是被你描述的这种情况烧伤的，所以我整合了一系列 SQL 卫生实践，以尽可能避免意外查询。

        回复

    5. 还可以将该查询返回的行数添加到 LIMIT 子句中，然后在生产环境中运行这个可怕的命令。

      回复

      1. 但这种情况一直在发生。人们会沾沾自喜。

        回复

    7. 在事务中进行每一次操作，在只读连接上进行测试，并请专人审核！

      如果需要更改大量记录，请与团队一起计划操作，因为如果需要很长时间，可能会导致表死锁！

      回复

      1. 我听到的意思是让实习生访问 prod，忽略他们团队的信息，然后过一个长周末？

        回复

        1. 我说过周一一切都会过去吗？我是说周一就会结束！

          回复

          1. 我周一不在，所以那是别人的问题。

            回复

    8. 或者，你知道的，通过主键具体确定要更新的记录。

      回复

    11. 这就是为什么我总是最后写更新（或删除、或更改或其他）…. 先写选择语句。

      是的，这很麻烦，而且要多花一分钟。有好几次我都是这么做的。

      回复

    13. 直到你尝试高亮显示查询，但却完全忽略了你的 where 子句，因为为什么我的系统管理员要过周末……

      我欠那家伙一顿午餐

      回复

  2. 有两种人：一种是使用事务的人，另一种是还没有使用事务的人。

    回复

    1. 不，我喜欢刺激。真正的技巧是在同一个查询编辑器中混合 30 种不同的命令，并确保突出显示正确的命令

      回复

      1. 我在这个评论里，我不喜欢它。

        回复

      2. ……最近把 SQL 客户端换成了一个工作方式有点不同的客户端后…

        回复

        2. 几个月前，在更换客户端后，我失去了几年的时间，肌肉记忆背叛了我，我使用了一个快捷方式，执行了整个文件，而不是突出显示的部分… 幸好我关闭了自动提交功能，所以我只是回滚了所有内容

          回复

      3. 啊，把它们全部注释掉，然后高亮显示要运行的内容（shift+alt 用于从特定列中多行选择）。

        回复

      5. 是的，你需要一个新的客户端。我已经很久没有高亮过语句了。

        回复

    3. 啊，当初级开发人员的美好时光

      回复

    4. 笑死我了，我还记得我和其他几位前辈在电话里讨论一个中级开发人员的问题，他当时正在共享屏幕，我只记得我大声说：“你在一个勇敢的 MFer 上更改了事务之外的生产数据”。他还没想过这个问题，笑。当他改变事务模式时，我们都开始集体大笑。

      回复

    5. 回滚

      没有可回滚的事务。

      哎呀呀

      回复

      1. 回滚

        没有要回滚的事务。

        “啊，这么说我们没有使用隐式事务。啧啧啧”

        回复

      1. 它就像一个 “atomar query”（原子查询），但被翻译成多个查询。

        也就是说，当你开始一个事务时，你可以做任何你想做的事情，通过回滚，你可以回到事务开始之前。

        回复

        1. 哦，天哪，真希望我两天前就知道这一点，当时我不小心把一个有上千人使用的个人项目的表清除到了 prod 而不是 dev 💀😂

          回复

          1. 给你这种技术水平的人这么多权限是他们的错。这不是你的错，每个人一开始都是绝对的菜鸟（不是说你是菜鸟！）。

            回复

            1. 哦，不，这不是我工作的一部分，这是我个人的 Discord 机器人

              我只是忘了我看的是生产数据库，而不是我的开发人员数据库 😭🤣

              我是一名中级开发人员，正在考虑晋升为高级开发人员，工作…. 可怕的想法，对吧？🤣

              回复

              1. 不，兄弟，别让冒名顶替综合症影响你。你能得到晋升就证明了你的能力，不要怀疑自己。

                我之所以认为你技术水平低，只是因为你这样表达自己。但是，没有人可以什么都懂，总会有新的东西需要学习。

                继续努力，相信自己！

                回复

                1. 最 “可怕 ”的是，我一直受到保护，不会犯这些错误……但作为一名高级员工，我将真正接触到实时系统。

                  哦，想象一下，因为你放错了一张表，导致公司整个产品线瘫痪🤣😰😨。

                  回复

                  1. 我的建议是把连接到 prod 和连接到 Dev 的主题换成不同的颜色。你可以修改 ssms 中的主题文件，其他集成开发环境可能也有相应的解决方案。如果你是通过控制台来管理它们，那么可以更改终端字体。

                    回复

                  2. 这种情况有可能发生，但你不会是第一个。

                    如果你害怕发生这种情况，那就执行 regurlar 备份吧

                    回复

                  3. 请告诉我，访问实时系统需要一套与你的 “正常 ”证书不同的证书。即使你能在需要的时候得到它，但只要你不需要修改 prod 数据，就能退出这类东西，这也是有帮助的。

                    回复

                  4. 在运行任何查询之前，请三思而后行；如果您使用的是专用数据库软件，请尽可能在配置中突出任何具有写入 prod 权限的连接。

                    我想我们现在已经把它锁定了，但我曾经拥有直接写入我们的 prod 数据库的权限，为此我把连接命名为 “PROD WRITE!!!!!!”，并把它的每个标签都设为鲜红色。

                    我用过的大多数数据库管理器都有一个选项，可以将连接标记为 “Prod”，这样它就会对你进行双重检查，或者真正做到一目了然。

                    回复

                  5. 别担心，这种事情时有发生。

                    以前，我们的一位资深数据库管理员（你可以在亚马逊上买到他关于 Oracle 性能调整的书）在测试环境中截断了一个表。不幸的是，当时测试环境是 prod，表中包含的数据极不稳定，价值约 9000 万美元。

                    这是我职业生涯的开端，因为我是负责处理票据的初级人员，却找不到这个特定客户的任何数据。或分区……或表中的数据。我们花了一整天的时间（控制台工作 24 小时）才从备份和重做中恢复了数据。

                    最糟糕的事情发生在我身上，就是在 rm -rf * .dat 命令中删除了大约 200k 的数据。）

                    回复

              2. Y.. 你是一个没有听说过 dbs 事务的中层干部吗？

                回复

                1. 这并不奇怪。您可以使用主要与内部业务逻辑相关的代码工作，而不直接与数据库交互；或者您与数据库的交互可以隐藏在 ORM 之后。

                  我认为，公司有责任检查员工在达到一定的工作经验后，是否了解他们所使用的 101 种技术，并期望他们获得/（接触/分配使用）/这些技术。

                  回复

                2. 我猜它从未出现过 🤷‍♂️

                  回复

                3. 即将 “晋升为高级”。瞠目结舌……

                  在我生活的地方，如果没有听说过 DB 中的事务是什么，是完全不可能通过任何与编程相关的教育的。你会在新兵训练营里学到这些，你会在职业学校里学到这些，你会在大学里学到这些。甚至在做一些简单的 “我自己做的网站全栈教程 ”时也会学到。我还在想这到底是怎么回事。

                  我的意思是，这不是这个人的错。如果没有人教你，你是不可能懂的。但这显然是教育体制和人们如何就业的问题。我很想知道这种混乱发生在哪里。

                  回复

              4. 好了，现在你的腰带上又多了一点好学的经验。祝贺你！

                回复

              5. 像这样的错误，尤其是当它是一个个人项目而不是工作项目时，只会让你成为一个更好的开发人员。我是一个相当高水平的工程师。我能想到的错误我都犯过。诀窍在于从中吸取教训，确保不再发生。

                回复

                1. 哦，当然

                  在那件事发生后，我在树莓派上启动了一个复制数据库，并开始每 24 小时将生产数据复制到树莓派数据库上。

                  现在，如果我再搞砸了，我最多只能丢失 24 小时的数据 🤔

                  (在向我的经理表达我的挫败感时，他建议我可以把每天的数据转储到文本文件中🤔）。

                  回复

              7. 错误时有发生，我们都是人。这就是我使用事务的原因（作为一名后辈，我应该补充一点，我没有经验，而且很笨）

                好消息是 你再也不会犯这样的错误了。

                回复

          2. 正如人们提到的，事务至关重要。但另一个保护自己的方法是，无论何时要进行更新，都要先用完全相同的条件进行 SELECT，并确保所选记录的数量与预期更新的数量相匹配。

            回复

            1. 虽然 “LIMIT ”比不上事务，但也能帮上忙。(如果你把它搞砸了，你还是有可能弄坏数据库中的某些东西，但只是 LIMIT-行数，而不是所有东西）。

              回复

          5. 如果你使用了 “truncate table my_table;”，那么除非你的数据库支持闪回，否则你无法通过回滚将其恢复。如果你使用 delete 删除表中的所有记录，那么你的做法也是错误的。

            回复

      2. 别担心，如果你不使用数据库，就永远不会用到它，否则就会在某个倒霉的日子里学到它：)

        开玩笑。它就像视频游戏中的检查点。在事务模式下，你可以做任何想做的事，验证结果，然后要么提交，要么ROLLBACK。

        你还需要意识到，即使你没有明确使用事务，只要你做了任何修改，它本身就是一个事务，只是你看不到而已。

        这是一篇很好的 101：https://www.dnsstuff.com/sql-server-transactions（但绝不是一篇全面的文章）

        回复

      3. 说到 SQL 服务器…

        begin tran
update Users set Username = "ohshit"
rollback tran

        这会告诉你更新了 X 行，但回滚了更改，所以实际上什么都没变。然后将回滚替换为提交，并再次运行，它就会真正更新数据库，因为你告诉它提交所有更改，而不是保存它们。或者你也可以直接执行

        begin tran
update Users set Username = "ohshit"

        然后看看出现了多少计数，然后在 SSMS 的同一查询窗口中，根据您想做的事情运行回滚事务或提交事务。

        在安全封装手动数据库更新之外，事务的好处在于，对于长程序，你可以使用全有或全无的原子事务，在这种事务中，要么所有内容都更新成功并提交，要么如果中途出错，你就回滚，而不是提交，这样就不会让数据处于半改变的混乱状态。

        回复

        1. 还有一种情况是，我只是在每一步之前编写选择语句来验证数据转换，然后使用新发现的逻辑编写更新。

          回复

      4. 这基本上给了你一个撤销功能。您可以命令数据库提交（又称保存），只有这样，您的更改才会最终完成。但数据库也不会允许其他事务与你的事务 “冲突”。为此，它可以让未来的事务等待，如果这些事务也想访问你刚刚修改的内容的话（至少在修改时是这样，仅仅读取还算可以）。这意味着如果忘记提交，就会阻塞未来的事务，甚至停止生产。问我怎么知道的。

        回复

      5. YT 上应该有 Git 命令演示的视频，看一下吧

        回复

      6. 一切都是事务。只是有些 DBMS 有隐式提交语句。

        回复

      7. 事务允许你分叉数据库的状态，运行多个查询并提交（保存）或回滚（中止、取消、丢弃）。

        这样就可以进行破坏性更新或删除，并在提交前检查结果。

        这还能确保数据不会在多次查询之间发生变化。为了实现这一点，事务会导致数据库被部分锁定，在事务完成之前冻结所有其他客户端。锁定行为在很大程度上取决于数据库、事务类型、配置和使用的查询（由您或其他客户端使用）

        回复

    7. 对生产数据库进行开放式交互式事务的缺点是，在提交/回滚事务之前，可能会无意中锁定表。

      回复

      1. 这个。理论上是不错。但在我看来，他们并没有在繁忙的服务器上使用事务对大型生产数据集进行大规模更新。只要有一个地方出了问题，或者出现了随机死锁，你就会锁定所有接触过的表。而且还无法选择退出或停止回滚。

        最好有一个复制环境，并在那里运行查询以验证结果，而不是随便乱扔事务。

        回复

        1. 理论上是不错，但你并不总是拥有一个最新相关数据的副本。

          数据库紧急更新 prod 数据是一个非常棘手的问题。没有灵丹妙药。

          回复

          1. 哦，当然。我们的假设是，这并不是紧急情况，只是需要进行一次有风险的更新。

            对于紧急情况，你能做的最好的办法就是尽你所能解决它，然后在事后采取保障措施，防止再次出现这种情况。

            回复

    8. 没错。我当时想的是 “所以不要进行事务”，很简单

      回复

    9. 然后，那些使用有 “当我还没破坏它时，恢复到它的任何版本 ”指令的系统的人

      回复

    10. 我现在是第二个遇到类似情况的人。幸好只有 300 条记录，我们还原了它们，但后来我写了程序，告诉大家如何始终使用 TRANSACTION

      回复

    11. 只有大豆开发人员会 ROLLBACK，真正的开发人员会 COMMIT

      回复

    12. 这就是为什么在启动 psql 时，我总是将 AUTOCOMMIT 设置为关闭，这样就总是存在一个隐式启动的事务

      回复

    15. 不幸的是，在 prod 中更新数据时，即使事务也不是万无一失的。我见过另一个开发人员在 toad 中打开一个事务，结果锁定了 prod 中的一条重要记录，导致 prod 完全锁死。见仁见智吧。

      回复

      1. 是啊，没有什么是万无一失的。事务只是一个非常有价值的工具，它能防止很多危险的事情发生，仅此而已–在我看来，几乎每次你用手接触关键数据库时，使用它就足够了。

        回复

    16. 如果不小心提交了怎么办？

      回复

      1. 当然，事务并不是一种魔法，它能防止各种可能的愚蠢或倒霉行为；但它能让您检查更新结果，并在推出更新前三思而行。如果这对你来说还不够，那么与其说是事务在起作用，不如说是你在起作用。最重要的是，这样的错误会告诉你，你已经养成了做完更新后尽快键入 COMMIT 的习惯，并且只把事务看作是需要克服的烦恼，而不是有用的工具。这是一种非常错误的心态，你应该努力改正。

        回复

        1. 我从代码的其他地方复制了一些查询，但没有及时提交。不过幸运的是，我所在的公司对谁能查看生产数据库有严格的规定，所以开发人员都没有权限查看生产数据库。那是另一个团队的职责。我刚刚清除了一些内部暂存数据，那时我还只是个初级开发人员。我当时很生气，但大家都笑我太白痴，只是复制一个查询并执行它，从那以后我就再也没这么干过。他们只是运行一个脚本，重新填充数据库。

          回复

          1. 啊，我明白了。不过也是，运气太差了，你通常不会犯这样的错误。

            回复

    18. 不，我只是让我的服务器每两天做一次备份

      我只是让我的服务器每两天做一次备份而已。

      回复

  3. 这就是为什么要使用事务….

    回复

    1. 但是但是…. 我在脚本结尾写了 “提交”，所以我的脚本是自动的！！！？

      回复

  5. 没有什么比 sudo rm -rf /var/lib/postgresql 更好的了

    在 prod 服务器上

    回复

    1. 你们有访问生产数据库的 shell 权限吗？

      回复

      1. 你们有访问生产数据库的权限吗？我所在公司的工程师都没有权限（即使是只读权限），因为生产数据库中有敏感的客户数据。如果你想在生产数据库上运行一个查询，你需要来自不同部门的几个人检查你的查询不会暴露任何敏感信息。

        回复

        1. 在大公司是的。在小公司，只读用户就会 “咔嚓 ”一声。

          回复

          1. 只读？兄弟，我只是用 prod 凭据登录到一个不安全的 phpmyadmin（通过 .env 搜刮），为分析报告抓取数据。

            回复

            1. 我只是在硬盘板上用磁针修改位！

              回复

        2. 难怪通过支持修复错误需要 3-5 个工作日。开个玩笑… 小企业可没那么多闲工夫。我每周都会检查我的 prod 备份，任何/所有测试/更改都是在 prod 中完成的，并勤于自我更新（先选择查询，再选择事务进行双重检查）。虽然情况不是很好，但我没有时间或资源来管理两个数据库服务器、保持同步以及网络应用程序服务器。

          回复

        3. 在开发、测试、类似生产和用户验收环境中，最终用户可能会以你没有想到的方式弄乱数据……处理敏感信息是工作的一部分，无论你处理的是 Joe 和 Suzy Average 的信息，还是你的邻居或某个著名体育明星的信息，都不应该有关系，你只是不谈论它（永远），或者你入错行了。

          回复

          1. 不管你处理的是 Joe 和 Suzy Average 的信息，还是你的邻居或某个体育名人的信息，这都不重要，你只是不要谈论它（永远不要），否则你就入错行了。

            这对公司很重要。如果某个工程师不守规矩（或只是对裁员心存不满），造成数据泄露，就会对公司造成影响。当然，你可以事后起诉，但为什么要冒险呢？除了 “没有人会因为数据泄露而冒着坐牢的风险 ”之外，绝对有这样的疯子，而且你可能永远都不会知道。

            这对我来说也很重要： 我希望其他处理我数据的公司也能像我工作的公司一样保持警惕。虽然我知道我不会以任何方式影响这一点，但从道义上讲，如果我希望其他地方也能这样，那么我就会喜欢这里的一切。

            在开发、测试、类似生产和用户验收环境中，最终用户会以一种你没有想到的方式把数据弄得一团糟，这一点会让你大吃一惊。

            我还记得类似的事件。从数据库中查询数据来解决类似的问题，绝对可以采用删除所有敏感信息的方式（要么根本不请求，要么用脚本清理，用自动生成的数据取而代之），但要留下足够的线索来说明发生了什么。是的，这需要更多的工作。但这就是生活。

            处理敏感信息是工作的一部分

            不，不是的。处理信息是工作的一部分，确保程序员从数据库中得到的任何信息都不敏感则是另一部分（可能也是其他开发人员/安全工程师头疼的问题）。

            回复

        4. 是吗？我是我们的主要数据库管理员和数据库开发人员，也是我们产品数据库的系统管理员，拥有完全访问权限。我还能怎么管理它、编辑数据、编辑模式、部署变更、执行分析等？

          必须有人拥有最终权限，否则什么都做不了。别跟我说什么 “任何人都不能访问 prod 数据库 ”之类的废话。

          回复

          1. 必须有人拥有最终权限，否则什么也做不了

            当然。但拥有这种权限的人应该越少越好。而不是整个开发团队。

            回复

        5. 我所在公司的工程师都没有这个权限（即使是只读权限），因为生产数据库中有敏感的客户数据。

          这让我回想起早年在一家 F100 企业集团工作时的情景，当时坐在我附近的一位资深科学家在删除了 10 年前的整个制造数据库后，用最小声的声音与 IT 部门通了电话。

          回复

        6. 我们不应该这样做，但在下层环境中很难不看到明文连接字符串，而这些连接字符串恰好具有在产品中也能使用的凭据。

          回复

          1. 至少你不需要使用生产数据库。这已经比明确允许访问要好得多了:)

            回复

        7. 等等，你们在数据库中保留了未加密的敏感客户数据，而且在每次对生产数据库进行需要解密的临时查询时，都不需要申请具有解密权限的临时只读用户？

          回复

      3. 只针对新人，作为安全培训的一部分

        回复

    2. 有一次，我在 Windows 服务器上输入

       del /s/q

      我还没有按回车键。但我的大脑让我按了回车键，而不是退格键。我很高兴我的备份成功了。🫠

      回复

  6. 等等，等等，等等！

    为什么要花这么长时间？Why is this taking so long!

    回复

    1. ……就在这一刻，他知道自己搞砸了

      回复

  7. 我以前公司的一个同事就遇到过这种情况，数据库是传统数据库，但仍在使用，开发人员不知道如何恢复备份。

    回复

    1. 我的一位同事就是这样做的。 现在他是首席技术官

      回复

    2. 这就是为什么你要拼命说服管理层，不管他们还能从遗留系统中获得多少中等收入，都绝对不值得因为系统出了严重问题而名誉受损，而且没有人知道如何修复它，导致可能是关键业务系统的系统需要几周的周转时间。

      给客户一些体面的通知，然后关闭或更换它。看在上帝的份上，别再留着它了。

      回复

  8. 你知道，我自己也是个 DBA。

    回复

    1. 我也是。我运行访问数据库

      回复

  9. 这就是我使用 select 语句来编写更新语句的原因

    回复

    1. 然后你就忘了空行等于；

      回复

  10. 这就是你使用事务的原因，对吗？

    …

    对不对？

    回复

  11. 我也遇到过这种情况，在输入 where 条件之前不小心按了回车键，所以没有使用事务。幸好有一个并行填充的参考表，所以很快就解决了。

    回复

    1. 我也犯过一次这样的错误，现在我总是先键入 where 子句，然后返回键入 set 子句。

      回复

    2. 要么使用 Begin commit（始终是个好做法），要么永远不要在终端中使用破坏性查询。(如果你使用的是 ms sql，则应删除所有空行，因为那是一个;)

      回复

    3. 在什么环境下使用回车键执行语句？

      回复

  12. 你们这些人提到的事务从未在大型银行数据库中真正运行过，因为整个集群是一个活的有机体，0.005 秒就是一光年。你以为可以从备份中恢复吗？ 不，资金转账已经在不同的银行系统上执行了。无论如何，你都会受到伤害

    回复

  13. 我花了太长时间才意识到这是 WHERE 子句丢失的问题，而不是触发器的问题

    回复

    1. 更妙的是，通过点击并按住来保存它们，这样就不会根据显示屏大小丢失像素。

      回复

  15. 一定要先进行选择，确保获得正确的记录集，然后再将其编辑为更新。

    回复

  17. 对图片进行截图（不裁剪黑边）而不是下载图片的人，就是那些共享末尾带有所有跟踪参数的 URL 的人。

    回复

    1. 是的，不是。备份是时间点，比如昨晚或几小时前。当员工工作或客户办事时，备份就会非常过时。你将不得不向高管解释，上次备份后发生的所有工作都是垃圾，都是因为你。

      回复

      1. 而该数据库之外的任何其他数据或真相存储也会在时间跨度内中断。

        回复

      2. 如果只是逻辑备份。物理备份 + TX 日志可提供 PITR 功能。

        回复

  19. 哦，天哪。我第一份工作的某个白痴就是这么干的。将 prod DB 中的每个密码都更新为 12345。🤡🤡🤡

    回复

    1. 怎么……怎么会不小心做到这一点？

      回复

      1. 他只想更新一条记录，显然是在没有 where 子句的情况下突出显示了命令。🤡🤡🤡

        回复

      1. 不，它们是散列的，但没有盐，所以 12345 的散列值在任何地方都是一样的。

        回复

  20. 听起来像是关系数据库问题，使用 nosql

    回复

  21. 学会裁剪图片，JFC。

    怎么，点按图片直接保存太麻烦了？你宁愿同时按住电源键和音量键来截图？

    真他妈见鬼了。

    回复

  22. 好吧，你可以说你……打破了记录。

    BA DUM TSSS

    回复

  24. 第一天上班

    rm -R *

    以根用户身份登录后，将 $home 设为 /

    “嗯，花了很长时间… 哦，该死

    (感谢上帝，我们有每日备份并知道如何使用它们。这个故事的寓意是：早备份，勤备份。是的，15 年后，我竟然还在那里工作）

    回复

  26. 如果咖啡还不能唤醒你，这个肯定能

    回复

  27. 需要更新单行或几行时，我通常只使用行编辑器

    回复

  29. 是的，我喜欢这种感觉。胜过 10000 杯咖啡。

    回复

  30. 我不使用事务，只是为了能感受到一些东西

    回复

  31. 我不是程序员，但这让我笑得前仰后合。我今天看到的最有趣的事情。

    回复

  32. 对于 UPDATE 和 DELETE 语句，WHERE 子句应配置为强制性。回滚是一种方法，但这将大大减少问题。

    回复

    1. where 1=1

      *在 where 子句被设置为强制性两分钟后，有人在某个地方说

      回复

      1. 是的，有时我确实想删除所有内容

        回复

  35. 有胸毛的真男人在生产中都会这么做。

    回复

  41. 上世纪 90 年代，我曾使用过没有事务的 MS-DOS 4GL 数据库。

    那是一段可怕的时光！

    改用 SQL 和 Win2k 让我松了一口气。

    回复

  42. 难道没有 “模拟运行 ”选项吗？在这个选项中，它会向你显示有多少行会受到影响，并提供一些更详细的信息，这样你就可以看一看，然后说 “是啊，看起来还不错”，然后再真正重新运行命令？

    回复

    1. 这叫回滚……或者简单地说，就是在启动更新前进行选择

      回复

  45. sql 语句中的括号不正确。我也遇到过这种情况。事实上就是今天。

    回复

  46. 那就回滚事务，对吗？对不对？

    回复

  47. 开始事务

    你甚至不需要在最后输入回滚，如果你忘记了，事务就会被挂起。

    所以，一定要以这个开始。事实上，请将其添加到新查询窗口的默认值中

    回复

  48. 我不太了解 SQL，不知道是否有与之对应的方法，但我喜欢 Powershell 的原因之一就是它的 -WhatIf 参数，它可以告诉你在许多 cmdlet 上执行该参数时会发生什么。

    不过在外部 cmdlet 上运行该参数时，请查看手册，因为其中有些会写着“-WhatIf 对本 cmdlet 没有任何作用”，而你会发现实际上你只是在运行命令而已。

    回复

  50. 当 GO 在 WHERE 子句之前出现时… 我也遇到过这种情况。只是删除，而不是更新

    回复

  51. 比任何咖啡都更能唤醒你的清晨

    回复

  53. 这就是为什么你总是先把更新语句写成 select 语句的原因。

    回复

  54. 始终将代码封装在回滚事务中

    如果需要，在事务中包含一个选择查询，以确认您所影响的记录是您所期望的记录

    切勿通过突出显示/选择部分脚本在生产环境中运行查询。在事务中运行整个脚本。尤其是在生产系统上

    回复

  57. 事务

    总是写出与你想要的完全匹配的选择语句，然后返回并将其改为更新。

    回复

  58. 总是……总是…. 运行与更新相当的选择语句，以了解受影响的行数。看在上帝的份上，使用事务吧。

    回复

  59. 带一份 prod 下来测试。先在那里运行查询。

    回复

  60. 这就是学习如何快速恢复数据库的方法。

    回复

  63. 事务，是的。

    但 LIMIT 也适用于更新，而不仅仅是选择。

    回复

  64. MySQL –i-am-a-dummy 还存在吗？

    那就用它吧 🙂

    回复

  66. SQL 没有 UNDO 命令 “是什么意思？

    回复

  67. 情况可能更糟

    别忘了小强尼 DROP TABLES

    回复

  68. 我对这个嗤之以鼻……我喜欢好的 SQL meme，而这个相当不错！谢谢 OP 😝🖖✌️

    回复

  69. 新手的错误。这些备忘录一而再再而三地重复。

    回复

  72. 除非先发出 BEGIN，否则永远不要发出 UPDATE 或任何其他进行更改的语句。

    回复

  74. 始终以 BEGIN 开始 SQL 会话；

    回复

  75. 这里的人说你应该使用事务，你应该这样做，但是我不明白，是谁在他们醉醺醺的头脑中认为更新语法中 SET 在 WHERE 之前会更好？

    就我个人而言，我只是学会了在 set 之前写 where，而且显然是先用 select 查询来检查它。

    回复

  80. 我的前任删除了数据库中所有的零。不是条目为零，而是所有字符都为零。

    因此，51395 号样品现在的重量是 29 克，而不是 501395 号样品的 290 克。

    回复

  81. 这就是我们不使用实时数据库的原因。

    回复

  82. 在做这类事情时：

    使用事务，必要时回滚

    先使用选择

    预先输入查询，并请同事确认

    ty

    回复

  83. 你需要害怕回车键。

    你想按吗？你确定要按吗？你确定吗？再读一遍

    回复

  84. quick ctrl+z ctrl+z！不… 不！不！不！不！不！不！不！不！不！不！不！不！不！…

    回复

  86. 有时我在写更新时只用解码，以查看 SQL 工作台发出的 “无用更新 ”警告

    回复

  89. 兄弟，我不会编程，但我是唯一知道如何使用 chatgpt 的人，因此我是团队中唯一有资格取代开发团队的人 😔

    回复

  91. 在执行任何操作之前，BEGIN TRANSACTION。

    在构建写操作时，先编写 WHERE 子句。让 SQL 出现语法错误，直到准备好点击 Execute 并检查完毕后再执行

    确认一切正常后再 COMMIT

    回复

  92. Begin Transaction

    从表中选择字段

    更新表设置字段 = 值

    从表中选择字段

    Rollback transaction

    永远

    回复

  93. 观点： 您的节点模块有问题，您试图修复 3 个错误，但之后产生了数千个错误。

    回复

  96. 初级开发者：什么是事务？

    回复

  97. 我记得在使用 sqlmgr 之前，当你右键单击一个表时，它有一个 “选择前 1000 名 ”的设计器选项。它的功能与普通的新查询窗口/文件基本相同，只是针对新用户增加了一些功能。

    出于某种原因，我在 prod 数据库上打开了它。我需要进行更新，于是写了一条更新语句，但写到 where 时就停住了……为了安全起见，我在更新语句下面写了一条选择语句，以解决 where 的问题。 然后，我突出显示了选择语句并运行了查询。

    这时我才发现，模式根本不关心我选择了什么，而是做了一个没有 where 的更新

    回复

  99. 兄弟不知道先做选择，不知道事务，也不知道备份

    回复

  102. 在我从事生产工作的早期，我就这样做了。只能说这是一个值得学习的时刻

    回复

  103. 只有 1276 000 人？超过 800 000 000 呢？

    回复

  104. BEGIN TRAN

    UPDATE dbo.Users SET Address=’blabla’ WHERE Id=Id

    ROLLBACK TRAN

    更新 1,347,925 条记录

    “哦，哎呀。应该是 WHERE Id=3872。让我更新一下，然后再运行一次确认一下。”

    回复

  105. 不管你信奉的是什么神，在使用数据库之前一定要先转储

    回复

  106. 现在，你可以用 “帕德梅/阿纳金 ”来跟进了：

    我搞砸了一个 UPDATE，毁掉了数百万行。

    你关闭了自动提交功能，是吗？

    对不对？

    …

    回复

  107. ……你没有停用自动提交功能

    回复

  109. 如果你不知道如何使用事务来避免这种情况，你就不应该在生产中拥有访问权限。

    回复

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注