MySQL中DELETE权限不足报错需显式授权，行级控制须结合存储过程或视图，PostgreSQL需注意权限继承，生产环境应限制裸DELETE并依赖ROW格式binlog保障可恢复性。
DELETE 语句执行失败提示 ERROR 1142 (42000): DELETE command denied
这是 MySQL 中最典型的权限不足报错，说明当前用户没有对目标表的 DELETE 权限，哪怕能 SELECT 也不代表能删。
实操建议：
- 用
SHOW GRANTS FOR 'username'@'host';查看当前用户实际拥有的权限，注意检查是否包含DELETE（不是ALL PRIVILEGES就一定包含） - 权限必须显式授予到具体库表，例如：
GRANT DELETE ON mydb.users TO 'appuser'@'%';，不能只授mydb.*却漏掉DELETE - 如果用的是云数据库（如阿里云 RDS、腾讯云 CDB），控制台里看到的“只读账号”“高权限账号”是封装层概念，底层仍需检查实际 GRANT 语句是否含
DELETE
如何让不同角色只能删自己负责的数据行
单纯靠数据库级 DELETE 权限无法实现行级控制——MySQL 原生不支持基于 WHERE 条件的权限过滤。必须结合应用逻辑或视图 + 权限组合。
实操建议：
- 不要直接给应用账号
DELETE表权限；改用存储过程封装删除逻辑，例如创建proc_delete_order_by_user，内部校验user_id = CURRENT_USER()或传入的@current_role - 用视图限制可操作范围：建视图
v_orders_mine只暴露当前用户订单，再对视图授DELETE权限（注意 MySQL 5.7+ 才支持对视图删改） - 若用 ORM（如 Django、SQLAlchemy），务必在代码层加
WHERE user_id = ?条件，且禁用裸 SQL 拼接，否则权限控制形同虚设
PostgreSQL 中 REVOKE DELETE ON table FROM role 不生效？
PostgreSQL 的权限继承机制容易让人误判：即使你 revoke 了某 role 的 DELETE，它仍可能通过所属的 parent role 继承到权限。
实操建议：
- 查清权限来源：运行
SELECT rolname, admin_option FROM pg_auth_members m JOIN pg_roles r ON m.roleid = r.oid WHERE m.member = 'target_role'::regrole; - 撤销时要明确指定层级：
REVOKE DELETE ON TABLE orders FROM app_reader;，同时检查app_reader是否属于app_admin，后者是否仍有DELETE - 用
pg_has_role('user', 'role', 'member')辅助验证成员关系，避免凭印象判断
DELETE 权限和 binlog / 闪回功能的关系
有 DELETE 权限 ≠ 能安全删数据。一旦误删，能否恢复取决于 binlog 格式、保留时长及是否有配套工具链。
实操建议：
- 确认 MySQL 的
binlog_format是ROW（STATEMENT下部分 DELETE 无法精确还原） - 检查
expire_logs_days设置是否足够长（至少 3 天），否则 binlog 被自动清理后无法闪回 - 生产环境应禁止直接执行
DELETE FROM table，强制要求带WHERE且提前用SELECT验证范围；可考虑用pt-archiver工具替代裸 DELETE，自带干跑预检
DELETE 权限开关能覆盖所有场景。 
