咸鱼翻身记：DataGrip里玩转BEGIN/COMMIT/ROLLBACK，PostgreSQL事务稳如狗！

每天分享技术栈，开发工具等

嘿，咸鱼们！还在为数据库操作提心吊胆吗？怕改错数据没法撤回？怕操作一半程序崩了留个烂摊子？别慌！今天咱就用DataGrip这把瑞士军刀，把PostgreSQL的看家本领—— 事务（Transaction）给整明白！学会BEGIN、COMMIT、ROLLBACK这三板斧，让你的数据库操作稳如老狗，错了也能一键回滚！走起！

一、 事务是啥？为啥咸鱼也得懂？

想象一下，你去小卖部买瓶快乐水（可乐）和一包辣条：

1. 扫码付钱（扣你账户的钱）。
2. 老板给你可乐和辣条（增加他的库存，减少对应商品库存）。 问题来了：要是扫码成功扣了你钱，但老板刚拿起可乐，店里突然断电了！辣条没拿到，钱也没退，你懵不懵？老板也懵（库存乱了）！

数据库里也一样！比如你要同时做两件事：

1. 把你的存款减少100块（UPDATE 账户 SET 余额=余额-100 WHERE 用户ID='咸鱼A'）。
2. 把咸鱼B的存款增加100块（UPDATE 账户 SET 余额=余额+100 WHERE 用户ID='咸鱼B'）。

如果只执行了第一步（你钱扣了），第二步没执行（咸鱼B没收到钱）就出错了（比如网络断了、程序崩了），那你这100块不就人间蒸发了？这能忍？

事务（Transaction）就是来解决这种“要么全干成，要么全当没干过”的问题的！它把一组相关的数据库操作（比如上面的两个UPDATE）打包成一个不可分割的“原子”操作。

事务的四大护法（ACID）：

• A (Atomicity) 原子性：事务里的操作，要么全部成功（提交），要么全部失败（回滚），不会只执行一半。就像上面转账，要么都成功，要么都失败，不会出现钱扣了对方没收到的情况。
• C (Consistency) 一致性：事务执行前后，数据库的状态都得是合理的（满足所有约束，比如余额不能为负）。转账前总钱数是1000，转账后还是1000（只是从A挪到B了）。
• I (Isolation) 隔离性：多个事务同时操作时，互相之间感觉不到对方的存在（有不同隔离级别控制能看到多少）。
• D (Durability) 持久性：一旦事务成功提交（COMMIT），它对数据库的修改就是永久性的，即使系统崩溃也不会丢。

二、 DataGrip实战：三板斧(BEGIN, COMMIT, ROLLBACK)怎么耍？

环境准备：

• 数据库：PostgreSQL (已安装好，假设库名 ，表accounts：字段 id (主键), name, balance)
• 连接工具：DataGrip(实测截图走起！)
• 目标表数据预览（在DataGrip里双击表名就能看到）：

步骤1：打开DataGrip，连上你的PostgreSQL(参考咸鱼之前发的连接教程图，或者快速描述：左边Database窗口 -> +-> Data Source-> PostgreSQL-> 填服务器IP、端口(默认5432)、库名、用户名、密码 -> Test Connection绿灯亮 -> OK)

步骤2：新建查询窗口在DataGrip里，右键你的数据库连接(test_db)，选择 New-> Query Console。这就是你写SQL命令的战场！

步骤3：开启事务 - BEGIN;在查询窗口里，敲入：

-- 咸鱼提示：在查询窗口执行这行，表示一个事务开始了！接下来的操作都在这个“保护罩”里。
BEGIN;

执行它！(选中这行，点工具栏的绿色小三角▶，或者按快捷键Ctrl+Enter/ Cmd+Enter)。DataGrip左下角通常会显示Transaction: Active之类的提示，表示事务开始了！

步骤4：执行你的操作 - 模拟转账现在，执行扣款和加款：

-- 咸鱼A 给 咸鱼B 转账 100块
-- 操作1：扣咸鱼A的钱 (在BEGIN后面执行)
UPDATE accounts SET balance = balance -100WHERE name ='咸鱼A';

-- 操作2：给咸鱼B加钱 (紧接着操作1执行)
UPDATE accounts SET balance = balance +100WHERE name ='咸鱼B';

分别选中执行这两条UPDATE语句！(或者选中两条一起执行)。执行后，别慌着关窗口！在DataGrip里，你现在查accounts表，可能会看到数据变了（A:900, B:600）。但这只是你当前事务里看到的！别人还看不到！因为还没提交！

步骤5：提交事务 - COMMIT;(成功结局)如果上面两步都执行成功，没报错，你觉得OK了，那就提交，让修改永久生效：

-- 咸鱼提示：在查询窗口执行这行，表示“我确认了！永久生效吧！”
COMMIT;

执行COMMIT;后，DataGrip左下角提示会变成Committed之类。这时，修改才真正写入数据库，别人也能看到了。再查表，数据就是A:900, B:600。

步骤6：回滚事务 - ROLLBACK;(后悔药！)重头戏来了！假设你在BEGIN;之后执行操作时出错了，或者你执行完UPDATE后发现转错人了！怎么办？吃后悔药ROLLBACK;!

模拟出错：

再次开启事务 (BEGIN;)，执行：

UPDATE accounts SET balance = balance -50WHERE name ='咸鱼A';-- 操作1，成功
UPDATE accounts SET balance = balance +50WHERE name ='咸鱼C';-- 操作2，假设'咸鱼C'不存在！这条会报错！

执行第二条时，DataGrip会报错，比如 ERROR: update or delete on table "accounts" violates foreign key constraint ...或者 ERROR: relation "accounts" does not exist ...(假设表名拼错了)。事务里只要有一条语句失败，整个事务就失败了！

吃后悔药 - ROLLBACK;:

-- 咸鱼提示：看到报错别慌！执行这行，撤销这个事务里所有的操作！
ROLLBACK;

执行ROLLBACK;。DataGrip提示会变成Rolled back。这时，这个事务里做的所有修改（包括第一条成功的UPDATE扣款）都会被撤销！数据库恢复到BEGIN;之前的状态。查表，数据还是A:900, B:600（或者你上次COMMIT后的状态）。

三、 咸鱼划重点 & 避坑指南

1. 在哪执行？所有命令 (BEGIN, UPDATE, COMMIT, ROLLBACK) 都在DataGrip的查询窗口(Query Console)里执行！
2. 事务边界：BEGIN;是开始，COMMIT;或 ROLLBACK;是结束。没有显式BEGIN？PostgreSQL默认每条单独的SQL语句本身就是一个小事务（自动提交）。想打包多个操作，必须显式用BEGIN开头！
3. 数据可见性：在COMMIT;之前，只有你这个连接/事务自己能看见修改！其他连接查到的还是老数据。提交后大家才都能看到。这就是隔离性在起作用。
4. 连接断开/工具崩溃咋办？如果你BEGIN;了，做了一些操作，没提交(COMMIT)也没回滚(ROLLBACK)，然后DataGrip崩了或者你网络断了。放心！PostgreSQL检测到连接断开后，会自动帮你做ROLLBACK！不会留半拉子修改。
5. 工具版本差异提醒：DataGrip不同版本界面布局可能微调，但核心功能（查询窗口、执行按钮、事务状态提示）基本不变。PostgreSQL的事务语法 (BEGIN/COMMIT/ROLLBACK) 是标准SQL，非常稳定。主要注意连接驱动的兼容性，DataGrip一般会自动下载匹配的驱动。
6. Docker Compose 部署小贴士 (可选)：如果你是用Docker跑PG，docker-compose.yml里定义PG服务时，事务行为完全由PG自身控制，和宿主机环境无关。确保PG容器数据卷(volumes)持久化，保证 持久性(D)。事务逻辑代码层面完全一样！

四、 总结：咸鱼也能稳如狗

事务不是啥高深魔法，就是数据库给你的一个“安全操作打包袋”。BEGIN开袋，COMMIT封口确认，ROLLBACK直接连袋子扔了（当没发生过）。DataGrip让操作这些命令跟写普通SQL一样简单直观，还有清晰的状态提示。