Navicat执行SQL脚本前必须确认三件事：连接的目标服务器、脚本对应的具体数据库、SQL文件的字符编码；三者任一出错均可能导致脚本误执行或乱码失败。
Navicat 里执行 SQL 脚本前必须确认的三件事
直接在生产库上跑清理脚本等于在雷区跳绳——不是不能做，但得先踩实每一步。navicat 本身不提供事务回滚预览或数据变更模拟，execute 一按就真删。
- 确认连接的是目标环境：检查 Navicat 左下角状态栏的
host、database和用户权限，别在写着test_db的标签页里执行DELETE FROM prod_orders - 强制开启事务包裹：哪怕只是
SELECT验证，也先写BEGIN TRANSACTION;，再查再删，最后用ROLLBACK;测试能否撤回（注意：MySQL 默认 autocommit=1，需手动关） - 备份不是“导出结构”，而是
mysqldump --single-transaction --databases your_db > backup_20240520.sql这种级别——Navicat 的“备份”功能默认不包含CREATE DATABASE和权限语句，恢复时容易漏
WHERE 条件写错导致全表误删的典型场景
脏数据清理最常翻车的地方不是逻辑复杂，而是 WHERE 漏条件、字段名拼错、或类型隐式转换失效。比如想删掉 2022 年前未支付的订单，却写了：
DELETE FROM orders WHERE created_at < '2022-01-01' AND status != 'paid';
问题在于：status 字段可能是 ENUM('pending','paid','cancelled')，而 'paid' 在某些排序规则下会匹配 'PAID' 或空格变体；更危险的是，如果 status 允许 NULL，!= 'paid' 不会包含 NULL 行，结果漏删+误删并存。
- 永远用
IS NULL或IS NOT NULL显式判断空值，别依赖=/!= - 对关键字段加索引验证：在 Navicat 查询窗口执行
EXPLAIN SELECT * FROM orders WHERE created_at < '2022-01-01' AND status = 'pending';，确认type是range或ref，不是ALL（全表扫描） - 先
SELECT COUNT(*)再DELETE：把DELETE改成SELECT id, status, created_at，人工抽样 5–10 条看是否符合预期
Navicat 执行大批量 DELETE 的性能陷阱
一次性删 50 万行？Navicat 默认会把整条 SQL 发给服务端，MySQL 可能锁表、日志暴涨、甚至触发 max_allowed_packet 报错。它不会自动分批。
- 手动分页删除：用
DELETE FROM orders WHERE id BETWEEN 10000 AND 19999 AND status = 'draft';，配合SELECT MIN(id), MAX(id) FROM orders WHERE status = 'draft';算范围 - 避免
OFFSET分页：像DELETE FROM orders WHERE status = 'draft' ORDER BY id LIMIT 1000 OFFSET 10000在大偏移时极慢，改用基于主键的游标式删除 - 关掉 Navicat 的“自动提交”：菜单栏
Tools → Options → SQL Editor → Uncheck "Auto-commit"，否则每条DELETE都单独提交，无法统一回滚
清理后必须验证的两个隐藏状态
删完不等于干净。外键约束、触发器、缓存一致性这些 Navicat 不显示但真实影响业务的状态，很容易被忽略。
- 检查外键级联：如果
orders表有ON DELETE CASCADE关联到order_items，删订单时子表已清，但你可能根本没查过order_items是否还有残留——执行SELECT COUNT(*) FROM order_items WHERE order_id NOT IN (SELECT id FROM orders); - 确认触发器未异常终止：有些清理脚本会绕过应用层逻辑（如更新用户积分统计），而数据库触发器可能还挂着。查
SHOW TRIGGERS LIKE 'orders%';，手动补一次触发逻辑 - 别信 Navicat 的“影响行数”弹窗：它只显示当前语句结果，不反映存储过程内嵌的 DELETE 或事件调度器任务——得去 MySQL 的
information_schema.INNODB_TRX查是否有长事务阻塞
生产环境的数据清理没有“一键安全”，只有每次执行前多问一句：这条语句在从库上会不会卡住复制？binlog 里留下的那几 MB 日志，够不够支撑 2 小时内的精准闪回？
