首先让我提一下,我已经看了很多建议的问题,但没有找到相关的答案。这就是我正在做的。

我连接到Amazon EC2实例。我可以用这个命令登录MySQL根目录:

mysql -u root -p

然后我用host %创建了一个新的用户帐单

CREATE USER 'bill'@'%' IDENTIFIED BY 'passpass';

授予用户bill的所有权限:

grant all privileges on *.* to 'bill'@'%' with grant option;

然后我退出root用户,尝试用bill登录:

mysql -u bill -p

输入正确的密码并得到以下错误:

错误1045(28000):用户“账单”@“localhost”(使用密码:YES)的访问被拒绝


当前回答

操作系统:windows

我的错误信息是:

MySQL ERROR 1045(28000):用户'root'@'localhost'(使用密码:YES)被拒绝访问

我的原因是,我没有打开cmd与管理员权限。

所以我的解决方案是作为管理员打开cmd,然后它就工作了。

其他回答

解决方案是删除匿名(Any)用户!

我在别人设置的服务器上也遇到了同样的问题。我通常不选择在安装MySQL时创建一个匿名用户,所以没有注意到这一点。最初,我以“root”用户登录,并创建了几个“正常”用户(也就是仅在dbs上以用户名作为前缀的用户),然后注销,然后继续验证第一个正常用户。我无法登录。既不通过phpMyAdmin,也不通过shell。事实证明,罪魁祸首是这个“任意”用户。

当你输入mysql -u root -p时,你是在通过本地unix套接字连接到mysql服务器。

不管你给的授权是什么,'bill'@'%'只匹配TCP/IP连接。

如果你想要授予对本地unix套接字的访问权限,你需要授予'bill'@'localhost'权限,奇怪的是,这与'bill'@'127.0.0.1'不一样。

您也可以使用TCP/IP连接mysql命令行客户端,以匹配您已经授予的权限,例如运行mysql -u root -p -h 192.168.1.123或任何您的本地IP地址。

I discovered yet another case that appears on the surface to be an edge case; I can export to the file system, via SELECT INTO .. OUTFILE as root, but not as regular user. While this may be a matter of permissions, I've looked at that, and see nothing especially obvious. All I can say is that executing the query as a regular user who has all permissions on the data base in question returns the access denied error that led me to this topic. When I found the transcript of a successful use of SELECT INTO … OUTFILE in an old project, I noticed that I was logged in as root. Sure enough, when I logged in as root, the query ran as expected.

百分号表示所有ip,所以localhost是多余的…本地主机不需要第二条记录。

实际上有,'localhost'在mysql中是特殊的,它意味着通过unix套接字(或windows上的命名管道)连接,而不是TCP/IP套接字。使用%作为主机不包括'localhost'

MySQL用户帐户有两个组成部分:用户名和主机名。用户名标识用户,主机名指定用户可以从哪些主机连接。用户名和主机名的组合:

< user_name >的@ < host_name >的 您可以为主机名指定特定的IP地址或地址范围,或者使用百分比字符(“%”)使该用户能够从任何主机登录。

注意,用户帐户是由用户名和主机名同时定义的。例如,“root”@“%”与“root”@“localhost”是不同的用户帐户。

解决这个问题的方法非常简单!

在我的例子中,我已经将我的数据库(mysqldump)导出到一个转储文件中。 然后我将文件复制到目标服务器。 在这个目标服务器上,我创建了目标数据库 然后运行命令将复制的dumpfile导入目标服务器上的新目标数据库。

= = >错误!在这一点上,我只是得到了错误,你也得到了!

现在,想想看!你使用的用户,他在源数据库上有什么GRANT ?

他对新的目标数据库有什么情报? 我认为,你已经看到了问题和解决方案!

= = >解决方案!

所以我进入我的源数据库并导出我使用的用户的所有授权。 之后,我进入我的目标数据库并导入导出的GRANT。

瞧!在此之后,将目标服务器上的源数据库导入到新的目标数据库中工作,没有任何问题!

文字太多了,抱歉!但也许它会帮助某人解决一个问题:-)