不会自动回滚；MySQL仅在连接异常终止（如崩溃、网络中断、超时）且autocommit=0时主动回滚未提交事务，正常断开或autocommit=1下不回滚。
客户端网络中断后，DELETE 事务不会自动回滚，而是继续在数据库服务端运行——除非数据库主动检测到连接丢失并触发清理机制。
MySQL 中断后事务仍 RUNNING
MySQL 不会立即感知客户端断开，SHOW PROCESSLIST 里该会话状态仍为 Running 或 Updating，锁持续持有，其他事务可能被阻塞。原因在于 MySQL 默认依赖 TCP keepalive（通常 2 小时才超时），而非应用层心跳。
- 若事务已加锁（如
SELECT ... FOR UPDATE后 DELETE），锁不会释放，直到超时或 DBA 手动KILL -
wait_timeout和interactive_timeout控制空闲连接断开时间，但对正在执行的长 DELETE 无效 - 可通过
SELECT * FROM performance_schema.threads WHERE PROCESSLIST_ID = ?查看线程真实状态
SQL Server 中断后事务自动回滚
SQL Server 通过 Keep Alive 参数（默认 30 秒）检测客户端失联，一旦确认，立刻触发 LOP_ABORT_XACT 回滚未提交事务。
- 回滚动作写入事务日志，可查
fn_dblog(NULL, NULL)中LOP_ABORT_XACT记录 - 注意：30 秒是“检测窗口”，实际耗时受
Keep Alive Interval影响，往往略大于设置值 - 若用 SSMS 连接后断客户端网卡，服务端约 30 秒后回滚；若断服务器网卡，则几乎瞬时回滚
PostgreSQL 中断后事务仍在后台执行
PostgreSQL 的行为最危险：客户端断开后，后端进程（backend process）仍存活并继续执行 DELETE，占用 CPU、I/O 和事务 ID，且不释放行锁或表锁。
- 必须靠
pg_terminate_backend(pid)主动杀掉对应进程，否则它可能跑数小时 -
idle_in_transaction_session_timeout对已进入执行阶段的 DELETE 无效 - 监控关键指标：
pg_stat_activity.state = 'active'+backend_start时间偏移
真正容易被忽略的是：不同数据库对“网络中断”的响应粒度完全不同——MySQL 等不及你，SQL Server 有底线，PostgreSQL 则默认“干完再说”。拆分大 DELETE 前，先确认你用的是哪个数据库的脾气。
