学SQL，谁还没过差点把表删了的时候？

别笑，你也过不了第二关！

我是小耶，干运营半路出家的野生DBA——写功课只是为了我踩过的坑，你们别再踩啦！

学SQL第二周，想查一个数据。脑子里想的是SELECT，手指敲出来的是：

DELETE FROM employees WHERE name = '张三';

手悬在回车键上，心跳起飞。还好多看了一眼，没敲下去。

后来一问，这事儿太普遍了：

• 有人把UPDATE写成DROP
• 有人DELETE忘了加WHERE，整张表清空
• 最惨的，在生产环境干过以上所有

为什么新手总在这里翻车？

不是不小心，是脑子想“查”，手指习惯“删”。

初级解法：先 SELECT 再动手

所有DELETE和UPDATE，先写SELECT看一眼。确认数据没错，再把SELECT *改成DELETE或UPDATE。

这招能救你无数次，但还不够。万一你忘了加WHERE呢？万一手一抖直接执行了呢？

进阶三板斧，专治手滑

第一斧：用事务裹住“改删”操作

把操作包进START TRANSACTION里，执行完别急着COMMIT，先SELECT看看影响行数对不对。

START TRANSACTION;
SELECT COUNT(*) FROM orders WHERE status = '测试';  -- 看一眼要改多少行
UPDATE orders SET status = '已完成' WHERE status = '测试';
-- 感觉不对？ROLLBACK 直接撤销
-- 确认无误？COMMIT

事务就是你的“时光机”，只要没提交，错了一键回到过去。

第二斧：批量操作带“刹车”

想清空历史数据？别用DELETE FROM table（锁表、记日志、慢到怀疑人生）。更安全的做法：分批删除。

DELETE FROM logs WHERE created_at < '2025-01-01' LIMIT 1000;

写个循环一次删1000行，重复到删完为止。对数据库冲击小，出问题最多丢1000行。

第三斧：生产库上变数据，必须走“双确认”流程

我给自己定了一条铁律：任何修改生产数据的操作，必须两双眼睛看过。

• SQL发给同事瞄一眼
• 在一个事务里执行，SELECT影响行数后，别急着COMMIT，再查一遍业务数据对不对
• 凌晨操作提前写好回滚脚本（把旧数据插回去的SQL）

别信自己的手，信流程！

比删错更痛苦的，是跑不动

安全第一关过了，但SQL写出来跑不动也够你受的。

执行后半天没结果，不知道是卡了还是慢了，只能干等，那咋办？

• 先加LIMIT 10，看能不能出数据
• 用EXPLAIN看执行计划，找出慢在哪
• 检查WHERE条件里的字段有没有索引

没有索引？数据库只能一行一行扫，几百万条数据，不慢才怪！

SQL没那么玄乎，新手期最难过两个坎：手滑删错和跑不动。

防手滑诀窍已经教给你们了，跑不动有EXPLAIN和索引，但这块坑很大，以后单开一篇细讲。

不过小耶在手，SQL不愁！

朋友们，你们写SQL最怕遇到什么报错呢？