故意删除MySQL 'root‘用户会触发其他MySQL帐户的“拒绝访问”

Question

我在生产中运行了一个MySQL 5.6，它有一个多年使用的遗留root帐户。作为一个强化程序的一部分，我想删除这个root帐户--通过另一个基本不命名为root的帐户来提供它。

在创建另一个名为adminacc的帐户并在DB上进行完全访问之后，我删除了名为root的帐户。在此操作之后，所有(adminacc仍可登录)我的其他帐户无法再登录接收以下消息

SQL State 28000 Error 1045: Access denied for user 'XXX'@'wathever' (using password: YES)

我在数据库上授予了拒绝帐户的全部访问权--但没有成功。最后，我重新创建了我的root帐户(使用相同的密码，不确定这里是否相关)，我的DB帐户返回了。

它怎么可能在帐户(它是初始root)和MySQL中的另一个帐户之间存在依赖关系？是不是因为我在以root用户的身份连接时创建了另一个帐户？还是另一个帐户试图查询由root帐户创建的视图？我相信没有，只是抛出想法试图去理解。

我觉得最奇怪的是，被拒绝帐户的连接并没有被完全拒绝。当测试来自Windows odbcad32.exe实用程序的连接时，它成功了！但是，无论何时在app上下文中使用(从同一个窗口主机运行)，它都失败了。

我确实运行了一个捕获，这是输出(这是来自应用程序上下文)

您可以看到登录实际上进行得很好；很少有查询是正确执行的(基本上是在会话开始时的init状态，如SET NAMES utf8或SET SQL_AUTO_IS_NULL = 0)。然后，当用户试图对其中一个DB视图执行SELECT时，会引发错误。

Nota:我发现MySQL文档中没有建议不要删除初始的root帐户。没有描述这种情况。我在网上浏览了一下，发现了以前的StackOverflow问题，但仍然没有人接。

Answer 1

正如阿金娜所解释的，这个问题与存储对象访问控制 in MySQL有关。这不仅适用于过程、函数、触发器，还适用于视图，请阅读以下内容

对于存储的例程(过程和函数)和视图，对象定义可以包含一个SQL安全特性，其值为定义者或调用者，以指定对象是在定义器还是在调用方上下文中执行。如果定义忽略了SQL安全特性，则默认为定义上下文。

当一个视图被调用时，我的错误实际上就会出现(而且所有的视图都是通过这个root帐户创建的，并且SQL SECURITY被设置为DEFINER -默认行为)。

现在很有意义了。尽管如此，MySQL错误消息本可以更多地描述实际问题！