MySQL：错误 2027 (HY000)：格式错误的数据包
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/45654055/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
MySQL: ERROR 2027 (HY000): Malformed packet
提问by Edvaldo Silva
I am not able to connect a MySQL server remotely. The connection seems to be ok because with telnet [ip] [port] I get response:
我无法远程连接 MySQL 服务器。连接似乎没问题，因为使用 telnet [ip] [port] 我得到响应：
4.1.3b-beta-nt-max? <0v '[uZ,? B {efSLa $, Q4N When executed by command line or by MySQL Workbench 6.3
通过命令行或 MySQL Workbench 6.3 执行时
mysql -u [user] -p -h [host]
I get the same error:
ERROR 2027 (HY000): Malformed packet
我收到同样的错误：
ERROR 2027 (HY000): Malformed packet
采纳答案by Roberto Gon?alves
It is a mysql client bug, I've searched about it and it is a old auth switch request. Your client it is out of date, using a old protocol communication, now, if it is a Workbench problem too your just the Client, you need to update or downgrade the MySQL Client first and try to run it alone.
这是一个 mysql 客户端错误，我已经搜索过它，它是一个旧的身份验证切换请求。您的客户端已过时，使用旧协议通信，现在，如果它也是工作台问题，您也只是客户端，则需要先更新或降级 MySQL 客户端并尝试单独运行它。
Here, it is the same question with a more complete answer: https://dba.stackexchange.com/questions/135343/server-responds-with-empty-packet-during-session-negotiation-resulting-in-client
在这里，它是相同的问题，有更完整的答案：https: //dba.stackexchange.com/questions/135343/server-responds-with-empty-packet-during-session-negotiation-resulting-in-client
And, for the new Auth protocol, on connection phase: https://dev.mysql.com/doc/dev/mysql-server/latest/page_protocol_connection_phase.html
并且，对于新的 Auth 协议，在连接阶段：https: //dev.mysql.com/doc/dev/mysql-server/latest/page_protocol_connection_phase.html
回答by Marcelo Amorim
You must upgrade the "old_password" hashed password:
您必须升级“old_password”散列密码：
SET PASSWORD FOR 'existinguser'@'localhost' = PASSWORD('existingpass');
SET PASSWORD FOR 'existinguser'@'localhost' = PASSWORD('existingpass');
So you can login in an "old" MySQL server, using a recent Workbench version
因此，您可以使用最新的 Workbench 版本登录“旧”MySQL 服务器
回答by Tomofumi
If you need to connect to pre-4.1 MySQL servers from later MySQL versions (5.7+), you will need to use "--skip-secure-auth" option from the client. And the client version cannot be newer than v5.7.4 because this option had been removed in 5.7.5. You can download version 5.7.4_m14 from mysql's archive website. For example,
如果您需要从更高的 MySQL 版本 (5.7+) 连接到 4.1 之前的 MySQL 服务器，则需要使用客户端的“--skip-secure-auth”选项。并且客户端版本不能高于 v5.7.4，因为该选项在 5.7.5 中已被删除。您可以从 mysql 的存档网站下载 5.7.4_m14 版本。例如，
$ mysql -uuser -p -hserver --skip-secure-auth
回答by Ravi Bhanushali
I did face this issue for normal select query. It was weird that when I was using small-case 's' in the query statement, it was giving me the same error. The I figured out that this happens as internally it is trying to retrieve the data from mysql cache. It was not because of the case of 's' in the select query.
对于普通的选择查询，我确实遇到了这个问题。奇怪的是，当我在查询语句中使用小写 's' 时，它给了我同样的错误。我发现这是在内部尝试从 mysql 缓存中检索数据时发生的。这不是因为选择查询中的 's' 的情况。
//Returned Error
select * from foo;
//This worked fine
Select * from foo;
//This also worked fine
select SQL_NO_CACHE * from foo;
From this I was able to conclude that it was the issue as it was using Cached data.
由此我能够得出结论，这是问题所在，因为它使用的是缓存数据。
回答by ryancey
I had the same error trying to connect to a MariaDB server with the MySQL client mysql-client. I solved it by installing mariadb-client(that overwrites the mysqlbinary, so use the same command to connect).
我在尝试使用 MySQL 客户端连接到 MariaDB 服务器时遇到了同样的错误mysql-client。我通过安装解决了它mariadb-client（覆盖mysql二进制文件，因此使用相同的命令进行连接）。
回答by Nazkter
For the people that has this error when the execute the query (not when connecting to DB), the problem is the cache configuration in database.
对于在执行查询时（而不是连接到数据库时）出现此错误的人，问题是数据库中的缓存配置。
You can find the bug description here:
您可以在此处找到错误描述：
https://bugs.mysql.com/bug.php?id=86318
https://bugs.mysql.com/bug.php?id=86318
The solution:
解决方案：
disable the cache configuration:
禁用缓存配置：
query_cache_limit = 0
query_cache_size = 0
query_cache_type = 0
In the long term there are no negative repercussions, since the latest versions of MySQL no longer support this feature. With little data the cache works correctly, but in large quantities it generates a bottleneck.
从长远来看，没有负面影响，因为最新版本的 MySQL 不再支持此功能。缓存在少量数据的情况下正常工作，但在大量数据时会产生瓶颈。
More info about the cache removed from mysql 8.0:
有关从 mysql 8.0 中删除的缓存的更多信息：
https://mysqlserverteam.com/mysql-8-0-retiring-support-for-the-query-cache/
https://mysqlserverteam.com/mysql-8-0-retireing-support-for-the-query-cache/
