告诉我们如何 DROP USER!

DROP USER

不久,我们将开始一项任务的编码,届时我们将非常感谢您的意见:您希望如何 DROP USER?

我们为什么问?

DROP USER(源自 2004 年的 MySQL)过去总是只从权限表中删除账户,但会保留所有现有连接处于活动状态。您可以说这在 2004 年是有疑问的,但在 2025 年,随着 MariaDB 的普及,这确实是出乎意料且令人困惑的。

所以现在我们正在考虑改变它。

但改变一个 20 年前的行为不能轻易为之。我们想问
您,我们的用户,您希望 DROP USER 执行什么操作。

有哪些选项?

您可能会问,DROP USER 有几种方式吗?是的,有!

我们面临几个选项——勾选您喜欢的

  1. 为了怀旧,保持旧行为。但这会让来自其他数据库的所有新 MariaDB 用户感到困惑。
  2. DROP USER 应该终止所有现有连接。
  3. DROP USER 应该等待所有现有连接终止。这是 MariaDB 在类似情况下的通常做法,例如,DROP TABLE 会等到表不再使用时才执行。
  4. 默认等待,但可以使用语法 DROP USER FORCE 选择性地调用终止。
  5. 除了 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