告诉我们如何 DROP USER!

不久,我们将开始一项任务的编码,届时我们将非常感谢您的意见:您希望如何 DROP USER?
我们为什么问?
DROP USER(源自 2004 年的 MySQL)过去总是只从权限表中删除账户,但会保留所有现有连接处于活动状态。您可以说这在 2004 年是有疑问的,但在 2025 年,随着 MariaDB 的普及,这确实是出乎意料且令人困惑的。
所以现在我们正在考虑改变它。
但改变一个 20 年前的行为不能轻易为之。我们想问
您,我们的用户,您希望 DROP USER 执行什么操作。
有哪些选项?
您可能会问,DROP USER 有几种方式吗?是的,有!
我们面临几个选项——勾选您喜欢的
- 为了怀旧,保持旧行为。但这会让来自其他数据库的所有新 MariaDB 用户感到困惑。
- DROP USER 应该终止所有现有连接。
- DROP USER 应该等待所有现有连接终止。这是 MariaDB 在类似情况下的通常做法,例如,DROP TABLE 会等到表不再使用时才执行。
- 默认等待,但可以使用语法 DROP USER FORCE 选择性地调用终止。
- 除了 DROP USER FORCE 之外,还添加一个标志值 old_mode=OLD_DROP_USER,这样 DROP USER 的行为就像选项 1 中所述,以便现有应用程序有时间迁移。
行动呼吁:参与我们的投票!
那么,我们应该怎么做?终止?等待?取决于情况?
请在下方投票。如果您有更详细的意见,请直接在 MDEV-35617 中发表评论。
感谢 Tadas 提醒我们!
注:这一切都在 MDEV-35617 DROP USER 应该不保留该用户的任何活动会话 中进行了讨论和描述。MDEV-35617 这个 bug 或特性是新的,始于十二月。之所以提出,是因为当前这种僵化的行为可能显得缺乏思考、麻木不仁和迂腐。
确实,MDEV 的报告者 Tadas Balaišis 对此感到意外
DROP USER 删除指定用户,而该用户有连接的会话存在。删除后,用户仍然可以在该会话中选择或修改数据。这是 bug 还是设计行为?我如何防止已删除用户在该会话中进行进一步操作?
Tadas Balaišis 在 MDEV-35617 中