最稳方式是直接用 SQL UPDATE，而非依赖“编辑单元格+保存”；DBeaver 的编辑数据模式逐行触发 UPDATE，并非全表覆盖，批量更新必须写 SQL。
直接用 SQL UPDATE 最稳，别依赖“编辑单元格+保存”
很多人点开表数据视图，手动改几行后点保存，以为能批量生效——实际只会提交你真正编辑过的那几行，其余没点进去的行完全不动。DBeaver 的“编辑数据”模式本质是逐行触发 UPDATE，不是全表覆盖。真要批量改一列，必须写 SQL。
常见错误现象：执行成功 0 行受影响，或只改了前几行就停住；也有人误以为勾选多行再右键“编辑”能批量赋值，但 DBeaver 不支持这种操作。
- 适用场景：整列统一更新（如把所有
status改为'processed'）、按条件更新（如WHERE created_at ）、带函数计算（如 <code>SET updated_at = NOW()） - 安全前提：务必先在测试环境验证语句，生产库建议加
WHERE条件并确认行数（可先用SELECT COUNT(*)预估） - 执行方式：打开 SQL 编辑器 → 写好
UPDATE→ 按Ctrl+Enter（Windows/Linux）或Cmd+Enter（Mac）运行
UPDATE 语句里别漏 WHERE，否则可能清空整列
DBeaver 不会拦截无 WHERE 的 UPDATE，它照常发给数据库。MySQL 默认允许这种操作，PostgreSQL 同样执行——结果就是整列被设成同一个值，且无法回退（除非有备份或 binlog）。
典型翻车现场：UPDATE users SET name = 'unknown'; —— 没加 WHERE，50 万用户全变 “unknown”。
- 强制习惯：写完
UPDATE后，先把光标移到WHERE关键字上，确认它存在、条件合理、能命中预期行数 - 快速验证：把
UPDATE改成SELECT *先跑一遍，比如SELECT id, name FROM users WHERE created_at - MySQL 用户注意：
sql_safe_updates=1是个保护开关，但 DBeaver 默认不启用该会话级设置，不能依赖
跨库批量更新？别用 DBeaver 界面，走数据传输向导
想把 MySQL 表 A 的 price 列，按 ID 匹配更新到 PostgreSQL 表 B 的同名列？这不是单条 UPDATE 能解决的。DBeaver 的「数据传输」功能专干这事，但必须选对模式。
容易踩的坑：在数据传输向导里选了“全量搬移”，结果把目标表整个 truncate 重写——这不是更新，是覆盖。
- 正确路径：右键源表 →「数据传输」→ 目标选已有表 → 映射字段时勾选“仅更新匹配行”（对应 PostgreSQL 的
ON CONFLICT DO UPDATE或 MySQL 的INSERT ... ON DUPLICATE KEY UPDATE） - 关键配置：在“设置”页勾选「使用合并插入（UPSERT）」，并确保源/目标表都有主键或唯一约束，否则无法判断“匹配”逻辑
- 性能提示：数据量大时，关闭「在行插入后执行提交」，改用大批次事务提交（如每 5000 行 commit 一次），避免长事务锁表
需要动态计算新值？参数化查询比拼字符串更安全
比如要把 score 列全部乘以 1.2，有人写 UPDATE exams SET score = score * 1.2;——这没问题；但若系数来自外部（如运营配置的折扣率），硬拼 SQL 字符串容易被注入或类型出错。
DBeaver 支持命名参数，但仅限于单次执行上下文，不适用于批量 UPDATE 中的列值计算。
- 推荐做法：用变量临时存值，再参与运算。例如 PostgreSQL：
DO $$ DECLARE discount_rate NUMERIC := 1.2; BEGIN UPDATE exams SET score = score * discount_rate; END $$; - MySQL 替代方案：
SET @rate := 1.2; UPDATE exams SET score = score * @rate; - 注意：变量作用域仅限当前会话，且不同数据库语法差异大，别跨库复用；DDL 类型变更（如 ALTER COLUMN TYPE）不能和 UPDATE 合并在一个语句里
批量更新最麻烦的从来不是怎么写语句，而是确认“改的是谁”和“改完能不能回滚”。DBeaver 提供了界面入口，但核心逻辑仍在 SQL 层——别让图形化掩盖了条件缺失、范围失控这些底层风险。
