Deadlock found报错是数据库服务端主动抛出的死锁异常，并非DBeaver导致；DBeaver仅原样显示该错误，其根源是多个事务以不一致顺序争抢同一组行锁形成循环等待，数据库检测后强制回滚牺牲者事务以保障一致性。
Deadlock found 报错不是 DBeaver 的问题
这个错误信息 Deadlock found（或更完整的 deadlock detected）根本不是 DBeaver 报的，而是 PostgreSQL / MySQL / SQL Server 等数据库服务端在事务执行过程中主动抛出的。DBeaver 只是把这条错误原样显示出来。它意味着：两个或多个事务互相等待对方持有的锁，数据库检测到循环依赖后，强制终止其中一个事务（即“选为死锁牺牲者”），并返回该错误。你不能靠改 DBeaver 设置来“关掉”这个报错——它是在保护数据一致性。
先确认是不是真死锁，还是单纯锁等待
很多人看到卡住就以为是死锁，其实大概率只是阻塞（blocking）。死锁会立刻报错；而锁等待会一直挂起，直到超时（如 PostgreSQL 默认 lock_timeout 未设则无限等，MySQL 默认 innodb_lock_wait_timeout=50 秒后报 Lock wait timeout exceeded）。
- 在 DBeaver 中打开新 SQL 编辑器，立即执行：
SELECT * FROM pg_stat_activity WHERE state = 'active' AND pid pg_backend_pid();
（PostgreSQL）或SELECT * FROM information_schema.INNODB_TRX;
（MySQL）看是否有长时间运行、state为idle in transaction或LOCK WAIT的会话 - 重点看
wait_event_type（PG）或TRX_WAITING_TRX_ID（MySQL）字段，有值才说明在等锁 - 如果查询本身也卡住，说明你连的这个连接可能已被自己或其他事务阻塞——换一个新连接去查
从 DBeaver 侧快速定位源头事务
DBeaver 自带的【会话监控】视图能帮你绕过命令行，直接看到谁在锁表、锁了多久、执行什么语句。
- 菜单栏 → 【窗口】→ 【显示视图】→ 【会话监控】（Session Monitor），确保已连接目标库
- 按
State列排序，重点关注idle in transaction（PG）或Locked（MySQL）状态的行 - 点开可疑会话的
Query列，看它最后执行的 SQL —— 很可能是没提交的BEGIN+ UPDATE/DELETE，或是 ALTER TABLE 这类重锁操作 - 右键该会话 → 【Cancel backend】（PG）或 【Kill session】（MySQL）可手动中断，但要确认它不是生产关键任务
避免下次再触发的关键实操习惯
死锁无法完全杜绝，但绝大多数都源于可预测的模式。DBeaver 不会帮你自动规避，但你可以用它养成防御性操作习惯：
- 所有手动写的 DML（UPDATE/DELETE/INSERT）前，先加
BEGIN，执行完立刻COMMIT或ROLLBACK，别让事务空悬；DBeaver 默认是自动提交（Auto-commit）开启的，但一旦你手动点过【事务】→ 【开始事务】，就必须自己管到底 - 跨表更新时，始终按固定顺序访问表（比如总是先 users 再 orders），避免 A 事务锁 users→orders、B 事务锁 orders→users 的交叉
- 在 DBeaver 的【SQL 编辑器】里写长事务前，先用
EXPLAIN ANALYZE看执行计划，避免隐式全表扫描导致锁范围过大 - 别在 DBeaver 里对大表执行
ALTER TABLE ... TYPE或ADD COLUMN DEFAULT—— 这类操作在 PG 中默认要拿ACCESS EXCLUSIVE锁，三千万行表一改就是几十分钟锁表，极易引发连锁阻塞
真正麻烦的从来不是报错那一刻，而是你点开会话监控后，发现那个 idle in transaction 的 PID 对应的 SQL 是一条没加 WHERE 的 UPDATE，而它已经挂在那里两小时了。
