mysql和postgresql均不支持对数据库内所有表批量授予delete权限；postgresql可用alter default privileges实现新表自动授权，mysql只能逐表脚本化生成grant语句，并需验证权限生效。
grant delete 权限时必须指定具体表名
mysql 和 postgresql 都不支持对“某个数据库里除系统表外的所有表”批量授 delete 权限；grant delete on database.* 看似可行，实则只对当前已存在且用户有 select 权限的表生效，新表不会自动继承，而且多数生产环境已禁用通配符授权。
- PostgreSQL 中
GRANT DELETE ON ALL TABLES IN SCHEMA public仅影响执行时已存在的表，后续新建表需单独再授或配合ALTER DEFAULT PRIVILEGES - MySQL 8.0+ 支持角色（role），但角色绑定的权限仍需按表显式授予，无法靠角色自动覆盖未来表
- 直接给
DELETE权限到库级（如database.*）在审计和最小权限原则下基本不被接受，DBA 通常会拒绝该申请
用 ALTER DEFAULT PRIVILEGES 控制新表默认权限（PostgreSQL）
这是 PostgreSQL 实现“未来表自动获得 DELETE”的唯一可靠方式，但它只作用于当前会话中由指定用户（或角色）新创建的表，不是全局策略。
- 先确保目标角色已存在：
CREATE ROLE data_cleaner - 切换到拥有建表权限的用户（如
app_owner），执行：ALTER DEFAULT PRIVILEGES FOR ROLE app_owner IN SCHEMA public GRANT DELETE ON TABLES TO data_cleaner;
- 此后
app_owner在public下新建的表，data_cleaner自动拥有DELETE权限 —— 但已有表仍需手动补授：GRANT DELETE ON TABLE users, orders TO data_cleaner; - 注意：该设置不传递给嵌套角色，也不影响其他 schema 或其他创建者
MySQL 中只能逐表 GRANT，但可脚本化生成语句
MySQL 没有类似 DEFAULT PRIVILEGES 的机制，必须对每张目标表显式执行 GRANT。人工写太容易漏，建议用查询动态生成授权语句。
- 假设清理脚本只需操作
logs、tmp_events、staging_users这三张表，在对应库中运行：SELECT CONCAT('GRANT DELETE ON `mydb`.`', table_name, '` TO ''cleaner''@''%'';') FROM information_schema.tables WHERE table_schema = 'mydb' AND table_name IN ('logs', 'tmp_events', 'staging_users'); - 复制输出结果，粘贴执行即可；别忘了最后
FLUSH PRIVILEGES; - 如果表名来自配置文件或变量，建议把生成逻辑封装进部署脚本，避免上线时遗漏
- MySQL 5.7 对
GRANT语句大小写敏感，table_name必须与实际定义一致（尤其含大小写混用时）
权限生效延迟与连接复用问题
授完权不代表脚本立刻能删——旧连接可能还缓存着旧权限上下文，尤其用连接池或长连接时。
- PostgreSQL 不需要重启连接，但需等待事务结束；如果脚本正在一个未提交事务中，新权限要等该事务结束才可见
- MySQL 中，
GRANT后部分客户端（如某些 Python MySQLdb 连接）会继续用旧权限，直到重连；简单加个REVOKE再GRANT并不能刷新现有连接 - 最稳妥做法：让清理脚本启动时主动断开并重建数据库连接，或在授权后明确要求 DBA 执行
FLUSH PRIVILEGES（MySQL）或通知应用重启连接池 - 权限变更后务必用目标账号登录验证：
SHOW GRANTS FOR 'cleaner'@'%';，别只信“执行成功”提示
实际落地时，最容易被跳过的其实是权限验证环节——很多人授完权就跑脚本，报 ERROR 1142 (42000): DELETE command denied 才回头查，其实花 30 秒用对应账号连进去 SELECT * FROM information_schema.role_table_grants（PG）或 SHOW GRANTS（MySQL）就能避开大半问题。
