DBeaver表格视图的“删除按钮”仅执行单行DELETE，不支持WHERE批量删除；安全批量删须在SQL编辑器中手写DELETE语句并用事务控制。
直接用 DELETE 语句加 WHERE 条件就能批量删，但必须确认事务没自动提交、条件写对、且没漏掉关键约束。
为什么点“删除按钮”只删一行，不是批量删？
DBeaver 表格视图里的“删除按钮”（或快捷键 Del）本质是图形化行级操作：它只作用于你当前选中的行，哪怕你 Ctrl+Click 多选，也只会把每行转成一条独立的 DELETE 语句逐条执行——不是真正意义上的 SQL 批量条件删除。
- 它不接受 WHERE 表达式，无法按字段值、范围、模糊匹配等逻辑筛选
- 误操作多选后点保存，可能删错数据，且无回退提示
- 底层实际执行的是类似
DELETE FROM t WHERE id = ?的参数化单行语句
怎么安全地执行带 WHERE 的批量 DELETE？
必须切到 SQL 编辑器，手写 DELETE 语句，并配合事务控制。这是唯一可控、可复核、可回滚的方式。
- 先写好语句，例如：
DELETE FROM users WHERE status = 'inactive' AND created_at - 在 DBeaver 中打开 SQL 编辑器（右键数据库 → “SQL 编辑器”），粘贴并执行
- 务必在执行前加
START TRANSACTION;，删完先不COMMIT，用SELECT验证是否删对了 - 确认无误再
COMMIT；出错就ROLLBACK - 别依赖“执行 SQL 脚本”图标（
Execute SQL Script）自动开事务——MySQL 默认 autocommit=1，它不会帮你包一层事务
MySQL 下 DELETE 带 LIMIT 算不算安全？
加 LIMIT 只能限制删多少行，不能替代 WHERE 的逻辑准确性，而且有隐藏风险：
-
DELETE FROM logs WHERE level = 'DEBUG' LIMIT 1000;看似稳妥，但如果表没主键或没索引，MySQL 可能每次扫全表找匹配行，性能差还不可预测 - 在复制环境（如主从）中，
LIMIT可能导致主从不一致，尤其涉及非确定性排序时 - 它不解决“删错条件”的问题——比如把
status = 'draft'写成status = 'drfat'，加 LIMIT 也没用 - 真正安全的做法是：先
SELECT COUNT(*)和SELECT * LIMIT 5预查，再删，最后再SELECT COUNT(*)对比
ClickHouse 或其他数据库的 DELETE 注意点
不是所有数据库都支持标准 DELETE ... WHERE。比如 ClickHouse 的 ALTER TABLE ... DELETE WHERE 是异步、最终一致的，且必须带 WHERE，否则语法报错。
- ClickHouse 示例：
ALTER TABLE events DELETE WHERE event_time - 它不会立刻生效，需等后台合并（merge）完成，期间仍可能查到旧数据
- 执行后要查
system.mutations确认状态，不能只看返回“OK” - PostgreSQL 支持
DELETE ... RETURNING，可顺便拿到被删行内容用于日志；MySQL 不支持，得靠触发器或提前INSERT INTO log_table SELECT ... FROM ... WHERE ...
最常被忽略的是：没在事务里执行、没预查结果集、没关 autocommit、以及把图形化删行和 SQL 条件删混为一谈。这四点踩中任意一个，删库跑路的概率就大幅上升。
