事务控制语句必须成对出现在同一连接中，BEGIN开启事务仅对当前连接有效，断连则自动回滚；COMMIT使修改持久化并可见，ROLLBACK撤销所有操作；DDL隐式提交，嵌套事务多为语法糖，SAVEPOINT支持子事务；autocommit状态决定BEGIN是否生效，ORM通常自动管理但原生SQL需手动处理。
事务控制语句必须成对出现在同一个连接里
MySQL、PostgreSQL、SQL Server 等主流数据库中，BEGIN（或 START TRANSACTION）开启的事务，只对当前数据库连接有效。一旦连接断开，未提交的事务自动回滚，COMMIT 或 ROLLBACK 都失效。
-
BEGIN不是函数，不能加括号；某些数据库（如 SQL Server）用BEGIN TRAN，但 PostgreSQL 和 MySQL 只认BEGIN或START TRANSACTION - 执行
COMMIT后，所有已修改的数据才真正写入磁盘并可见给其他连接；之前只在本连接内可见 - 如果程序中途崩溃、网络中断或显式调用
ROLLBACK，所有INSERT/UPDATE/DELETE操作全部撤销，就像没发生过 - 注意：DDL 语句（如
CREATE TABLE、DROP INDEX）在多数数据库中会隐式触发COMMIT，导致前面的事务提前结束
嵌套事务在大多数数据库里只是语法糖
像 BEGIN 套 BEGIN 这种写法，MySQL 完全不支持；PostgreSQL 允许但实际没有嵌套语义——ROLLBACK 总是回滚到最外层 BEGIN，不是最近一层。
- PostgreSQL 提供
SAVEPOINT实现真正的“子事务”控制：SAVEPOINT sp1→ROLLBACK TO sp1 - SQL Server 支持命名事务（
BEGIN TRAN t1），但ROLLBACK TRAN t1仍会回滚整个外部事务，除非配合SAVE TRANSACTION - 不要依赖“嵌套
BEGIN”来分段控制，容易误判回滚范围
自动提交模式（autocommit）关不关，直接影响 BEGIN 是否生效
默认情况下，MySQL 客户端和 JDBC 驱动都开启 autocommit；此时每条 INSERT 都自动 COMMIT，BEGIN 之后的操作看似在事务里，其实只要 autocommit 开着，BEGIN 就被忽略。
- 确认当前状态：执行
SELECT @@autocommit（MySQL）或SHOW VARIABLES LIKE 'autocommit' - 关闭它：
SET autocommit = 0（MySQL），或用客户端配置（如 Python 的conn.autocommit = False） - PostgreSQL 默认 autocommit 关闭，所以
BEGIN总是有效；但 pgAdmin 等 GUI 工具可能默认开启，需检查设置 - ORM（如 Django、SQLAlchemy）通常自动管理 autocommit，但手动写原生 SQL 时必须自己处理
COMMIT 失败通常意味着连接已断或事务被强制终止
正常情况下 COMMIT 不会报错；一旦出现 ERROR 1312 (HY000): COMMIT is not allowed in a stored function or trigger 这类提示，说明你正在函数/触发器里执行了它——这是数据库硬性限制。
- 常见错误现象：
COMMIT执行后查不到刚插入的数据？先确认是否忘了SELECT时加了FOR UPDATE或隔离级别影响 - 长时间未
COMMIT的事务会占用锁、阻塞其他操作，MySQL 中可通过SELECT * FROM information_schema.INNODB_TRX查看活跃事务 - 不要在循环里反复
COMMIT，尤其大批量写入时——每次COMMIT都有 I/O 开销；建议每 1000 行左右批量提交一次
事务边界不是靠代码缩进或注释决定的，而是由连接生命周期、autocommit 设置和显式语句共同锁定的。漏掉一个 SET autocommit = 0，或者在 ORM 里混用原生 SQL 和事务方法，都可能导致你以为在事务里，其实每条语句都在单独提交。
