应仅授予批量删除账号在目标表上的delete权限，如grant delete on mydb.logs to 'cleaner'@'localhost'，禁用select、drop、alter等无关权限，并限制其仅本地连接与最大3个并发连接。
直接给执行批量删除的账号赋予 DROP USER 或 root 权限是危险且不必要的。你应该只授予它在目标表上做 DELETE 的最小权限，并隔离其操作范围。
只授权 DELETE 权限，不给 DROP、ALTER、SELECT 全局权限
很多运维习惯性给维护账号 GRANT ALL PRIVILEGES，但批量删除根本不需要读、改结构或删表能力。过度授权一旦脚本写错（比如 WHERE 条件漏写），后果就是全表清空。
-
GRANT DELETE ON mydb.logs TO 'cleaner'@'localhost';—— 仅允许删mydb.logs表 - 别加
SELECT：除非你要先查再删（此时应另起只读账号） - 别加
INDEX或ALTER：批量删不需要建临时索引或改表结构 - 确认执行后运行
SHOW GRANTS FOR 'cleaner'@'localhost';核对权限是否精简
限制账号只能连本地 + 设置连接数上限
批量删除操作通常由后台脚本或定时任务触发，不该暴露给网络。同时防止误启多个并发进程把数据库拖垮。
- 创建时指定
'cleaner'@'localhost'，禁止远程登录 - 用
MAX_USER_CONNECTIONS 3限制该账号最多 3 个并发连接 - 建账号语句示例：
CREATE USER 'cleaner'@'localhost' IDENTIFIED BY 'P@ssw0rd4Del!' WITH MAX_USER_CONNECTIONS 3; - 注意：MySQL 5.7+ 才支持
WITH MAX_USER_CONNECTIONS，老版本需靠应用层控制并发
避免使用 root 或 mysql.session 等系统账号执行删除
系统账号权限过大，且部分账号（如 mysql.session）被 MySQL 内部组件强依赖，一旦被锁或异常会影响复制、监控等关键功能。
- 不要用
root跑定时DELETE ... LIMIT脚本 —— 这等于把刀交给没训练过的人 - 不要复用
mysql.sys或mysql.session：它们的authentication_string是占位符，无法设密码，也不该用于人工操作 - 检查当前用户列表：
SELECT user, host, account_locked FROM mysql.user WHERE user NOT IN ('root', 'mysql.sys', 'mysql.session');
权限变更后必须 FLUSH PRIVILEGES
权限表修改后不会自动生效，尤其当你直接 INSERT/UPDATE mysql.user 表（不推荐）或用旧版 MySQL 客户端执行 GRANT 时，容易忽略这步。
- 执行完
GRANT或CREATE USER后，补一句：FLUSH PRIVILEGES; - 不执行这句，新账号可能连不上，或权限不生效 —— 常见于 Docker 容器里未重启 mysqld 的场景
- MySQL 8.0+ 在大多数 GRANT 场景下可自动刷新，但显式执行仍是稳妥做法
真正麻烦的不是授权动作本身，而是后续权限演进：比如某天要删另一张表，有人顺手加了 GRANT DELETE ON mydb.audit_log，却忘了同步更新连接池配置或脚本中的 WHERE 条件 —— 这类“权限蔓延”比初始配置错误更难追溯。
