基于 MySQL 8.0 细粒度授权：单独授予 KILL 权限的优雅解决方案

一、引言

作为一名数据库从业者，我在日常工作中经常会遇到一个棘手的问题：如何在保证安全的前提下，让业务团队拥有足够的权限去管理数据库执行的 SQL，尤其是终止那些失控的慢查询或异常线程？这个问题看似简单，却牵涉到权限设计、安全合规以及数据库稳定性等多方面的权衡。今天，我们就来聊聊 MySQL 8.0 如何通过权限体系的革新，特别是对 KILL 权限的细化支持，解决了这一痛点，并为 DBA 和业务开发团队带来了更大的灵活性。

二、从痛点说起：KILL SQL 的权限困境

在 MySQL 实际使用中，业务开发人员常希望拥有终止 SQL 的能力。例如，慢查询占用大量资源，或未优化的批量操作导致负载飙升，此时及时 KILL 问题 SQL 是最直接的解决办法。然而，MySQL 的权限设计限制让这一需求难以实现，开发人员往往只能依赖 DBA 操作，既低效又拖延响应。

在 MySQL 的传统版本（比如 5.7 及更早版本）中，KILL 权限的实现存在以下几个问题：

1. 执行用户限制 默认情况下，用户只能 KILL 自己创建的线程。若业务程序使用统一账号（如 app_user），开发人员想通过此账号终止 SQL，必须知道其密码并登录数据库执行 KILL。然而，企业安全规范通常禁止程序账号单点登录，因其权限过大（至少包括增删改查），导致开发人员无法直接操作。这形成了一个"权限死结"：想 KILL 无权限，有权限却无法登录。
2. SUPER 权限过大 为突破上述限制，允许用户 KILL 其他用户的 SQL，需授予 SUPER 权限。这看似可行，但 SUPER 权限是个“大杀器”：持有者不仅能 KILL 任何线程，还可修改全局参数（如 innodb_buffer_pool_size）、执行 STOP GROUP_REPLICATION 关闭组复制等操作（甚至会导致中断服务）。此权限通常仅限超级管理员使用，对业务开发而言明显过大，且存在严重安全隐患，DBA 自然不愿授予业务团队。

面对这样的困境，我们不禁会问：难道就没有一个两全其美的办法，既能让业务团队有 KILL SQL 的能力，又不至于权限失控吗？

答案是肯定的，MySQL 8.0 的到来，让这一需求成为了现实。

三、MySQL 8.0 的细粒度权限拆分：KILL 权限独立登场

MySQL 8.0 在权限体系上迎来重大改进，最显著的是对 SUPER 权限的拆分。在 5.7 及之前，SUPER 权限如同一个大包袱，功能过于庞杂。而 8.0 引入了动态权限（即运行时可分配的细化权限），将 SUPER 拆解为多个细粒度权限，其具体内容如下：

SUPER 被拆分为 10 个动态权限。同时，MySQL 8.0 因新增功能和组件，又引入了 29 个动态权限，构成以下 39 个动态权限列表：

其中，KILL SQL 可以使用 CONNECTION_ADMIN这个动态权限来单独授权。

SUPER 因权限过大的安全隐患，在 8.0 版本开始已经不建议使用。官方文档明确指出，SUPER 已被标记为即将废弃，推荐尽早迁移至动态权限体系。

SUPER is a powerful and far-reaching privilege and should not be granted lightly. If an account needs to perform only a subset of SUPER operations, it may be possible to achieve the desired privilege set by instead granting one or more dynamic privileges, each of which confers more limited capabilities. See Dynamic Privilege Descriptions.NoteSUPER is deprecated, and you should expect it to be removed in a future version of MySQL. See Migrating Accounts from SUPER to Dynamic Privileges.

具体到 KILL SQL 的场景，还有一些细节要注意，如果开发或业务 DBA 需要 KILL SQL，除了需要刚才讨论的 CONNECTION_ADMIN 权限外，还有一个前提，要求能看到对应的线程，这要求授予 PROCESS 权限，这样他执行 show processlist 时就可以看到所有用户运行的线程了，而非只能看到自己的线程。这个权限 5.7、8.0 通用，允许用户查看其他用户的线程，授权如下:

GRANT PROCESS ON *.* TO 'dev_admin';

注意，PROCESS 权限允许查看他人 SQL 原文，可能导致敏感信息泄露。建议业务部门自行评估安全风险，例如仅授权高级业务 DBA 查看全局 SHOW PROCESSLIST 并执行 KILL SQL。

拥有 PROCESS 权限的用户可按以下步骤终止问题线程：

1. 执行 SHOW PROCESSLIST; 查看运行线程列表，找到目标线程 ID。( 对应 PROCESS 权限 )
2. 执行 KILL

SHOW PROCESSLIST;
KILL 12345;

这样一来，业务团队就拥有了终止任意 SQL 的能力，而 DBA 也不必担心他们会误操作全局参数或关闭服务器。权限控制变得更加精细，安全性和灵活性得到了兼顾。

四、系统线程的安全防护：SYSTEM_USER 权限的加持

然而，细心的读者可能会提出一个问题：如果用户拥有了 PROCESS 权限，他们会不会一不小心 KILL 掉一些关键的系统线程，比如主从复制线程（Replication Thread）或后台维护线程？这确实是一个合理的担忧，因为系统线程一旦被误杀，可能会导致数据库服务中断，甚至引发数据不一致的风险。

MySQL 8.0 的设计者显然也考虑到了这一点。为了保护系统线程，他们引入了 SYSTEM_USER 权限。这个权限的作用是区分普通用户线程和系统线程，并为后者提供额外的保护。具体规则如下：

• 如果某个线程是由具有 SYSTEM_USER 权限的用户创建的（通常是 MySQL 的内置系统账号，比如复制线程的执行用户），那么普通用户（没有 SYSTEM_USER 权限）无法通过 KILL 命令终止它。
• 只有当前会话也具备 SYSTEM_USER 权限的用户，才能 KILL 掉同样具备 SYSTEM_USER 权限的线程。

这意味着，即便业务用户拥有了 PROCESS 权限，他们也无法干扰数据库的后台线程，比如主从复制线程、事件调度线程（Event Scheduler）或管理员的命令行。这种设计极大地提升了系统的稳定性，避免了权限滥用带来的潜在风险。

这就保证了普通用户无法越界操作，系统的核心功能得到了保护。

五、实战演练：如何优雅地使用 KILL 权限

1. 使用 dbops 搭建一主两从的 MySQL8.0.41 实例

dbops 是什么，见 http://dbops.cn

2. 创建程序账号 app_user，授予业务库 app_db 的增删改查权限

create user app_user identified by 'Dbops@2025';
grant select,insert,update,delete on `app\_db`.* to app_user;

3. 创建业务库、业务表，并执行长事务

4. 创建开发主管账号 dev_admin，授予查看全局 SQL 和 KILL SQL 权限

create user 'dev_admin' identified by 'Dbops@2025';
GRANT PROCESS ON *.* TO 'dev_admin';
GRANT CONNECTION_ADMIN ON *.* TO 'dev_admin';

5. 为后台线程账号（如 admin、repl）授予 SYSTEM_USER 权限，标记为受保护线程，普通用户无法 KILL

GRANT SYSTEM_USER on *.* to admin@'127.0.0.1';
GRANT SYSTEM_USER on *.* to admin@'localhost';
GRANT SYSTEM_USER on *.* to repl@'1%';

随后，重启复制线程，重新连接admin命令行窗口，让权限生效。

6. 测试 KILL SQL

受 SYSTEM_USER 保护的线程无法被终止。

而普通用户（如 app_user）的线程可被终止。

注意事项

在 MySQL 8.0 中，权限不足的错误信息因操作而异。例如，修改全局变量时：

mysql> SET GLOBAL TRANSACTION ISOLATION LEVEL REPEATABLE READ;
ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER or SYSTEM_VARIABLES_ADMIN privilege(s) for this operation

这明确指出所需权限。

但对于 KILL SQL，若缺少 CONNECTION_ADMIN 权限，错误信息却不同：

mysql> kill 66;
ERROR 1094 (HY000): Unknown thread id: 66

此提示具有误导性，无法区分是用户未被授予 CONNECTION_ADMIN，还是目标线程受 SYSTEM_USER 保护所致，测试时这两方面都可以注意一下。

六、总结与展望

MySQL 8.0 的细粒度权限体系，特别是动态权限的引入，有效缓解了传统版本“权限过大或过小”的困境。通过单独授予 CONNECTION_ADMIN 和 PROCESS 权限，业务团队无需 SUPER 权限即可安全管理异常 SQL 线程。而 SYSTEM_USER 权限则为系统核心线程提供了可靠保护，避免误操作导致服务中断。

dbops 默认创建 admin@'127.0.0.1'、admin@'localhost'、repl@'1%' 等账号。

欢迎讨论：是否在 dbops 1.10 新版本中支持 MySQL 8.4.x 尝鲜，默认为此三账号添加 SYSTEM_USER 权限，以进一步提升系统安全性？

参考:

https://dev.mysql.com/doc/refman/8.0/en/grant.html

https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html