錯誤代碼：2013。在查詢過程中失去與 MySQL 服務器的連接

Question

我收到錯誤代碼：2013。當我嘗試使用 MySQL Workbench 向表添加索引時，在查詢錯誤期間丟失了與 MySQL 服務器的連接。 我還注意到，每當我運行長查詢時它就會出現。

是否可以增加超時值？

Answer 1

新版本的 MySQL WorkBench 可以選擇更改特定超時。

對我來說，它是在 Edit → Preferences → SQL Editor → DBMS connection read time out (in seconds): 600

將值更改為 6000。

還有未經檢查的限制行，因為每次我想搜索整個數據集時都設置一個限制會讓人厭煩。

Answer 2

如果您的查詢包含 blob 數據，則可以通過應用此答案中建議的my.ini更改來解決此問題：

[mysqld]
max_allowed_packet=16M

默認情況下，這將為 1M（允許的最大值為 1024M）。 如果提供的值不是 1024K 的倍數，它將自動四舍五入為最接近的 1024K 倍數。

雖然引用的線程是關於 MySQL 錯誤2006 ，但將max_allowed_packet從 1M 設置為 16M確實修復了運行長查詢時出現的 2013 錯誤。

對於 WAMP 用戶：您將在[wampmysqld]部分找到該標志。

Answer 3

使用命令行選項net_read_timeout / wait_timeout和合適的值（以秒為單位）啟動數據庫服務器 - 例如： --net_read_timeout=100 。

有關參考，請參閱此處和此處。

Answer 4

將以下內容添加到 /etc/mysql/cnf 文件中：

innodb_buffer_pool_size = 64M

例子：

key_buffer              = 16M
max_allowed_packet      = 16M
thread_stack            = 192K
thread_cache_size       = 8
innodb_buffer_pool_size = 64M

Answer 5

SET @@local.net_read_timeout=360;

警告：當您在遠程連接中應用它時，以下內容將不起作用：

SET @@global.net_read_timeout=360;

Answer 6

您應該將 mysql 配置文件中的“interactive_timeout”和“wait_timeout”屬性設置為您需要的值。

Answer 7

我收到錯誤代碼：2013。當我嘗試使用MySQL Workbench向表中添加索引時，在查詢錯誤期間失去了與MySQL服務器的連接。 我還注意到，只要我運行長時間查詢，它就會出現。

是否有增加超時值的方法？

Answer 8

此錯誤消息有三個可能的原因

1. 通常表示網絡連接有問題，如果經常出現此錯誤，您應該檢查網絡狀況
2. 有時，當作為一個或多個查詢的一部分發送數百萬行時，會出現“查詢期間”表單。
3. 更罕見的是，當客戶端嘗試與服務器進行初始連接時會發生這種情況

更多詳情請閱讀>>

原因2：

SET GLOBAL interactive_timeout=60;

從默認的 30 秒到 60 秒或更長

原因3：

SET GLOBAL connect_timeout=60;

Answer 9

就我而言，將連接超時間隔設置為 6000 或更高的值不起作用。

我只是做了工作台說我可以做的事情。

查詢從 DBMS 返回數據所需的最長時間。設置 0 以跳過讀取超時。

在 Mac Preferences -> SQL Editor -> Go to MySQL Session -> 將連接讀取超時間隔設置為 0。

它有效😄

Answer 10

只需執行 MySQL 升級，將重新構建 innoDB 引擎，同時重建 MySQL 正常運行所需的許多表，例如performance_schema 、 information_schema等。

從您的 shell 發出以下命令：

sudo mysql_upgrade -u root -p

Answer 11

我知道它很舊，但在 mac 上

1. Control-click your connection and choose Connection Properties.
2. Under Advanced tab, set the Socket Timeout (sec) to a larger value.

Answer 12

如果您在恢復大轉儲文件期間遇到此問題並且可以排除它與網絡有關的問題（例如在本地主機上執行），那么我的解決方案可能會有所幫助。

我的 mysqldump 至少保存了一個對 mysql 來說太大而無法計算的 INSERT。 您可以通過鍵入show variables like "net_buffer_length";來查看此變量show variables like "net_buffer_length"; 在你的 mysql-cli 里面。 你有三種可能：

• 增加 mysql 內的 net_buffer_length -> 這需要重啟服務器
• 使用--skip-extended-insert創建轉儲，每個插入使用一行 -> 雖然這些轉儲更好讀，但這不適合 > 1GB 的大轉儲，因為它往往很慢
• 創建帶有擴展插入的轉儲（這是默認值）但限制 net-buffer_length 例如使用--net-buffer_length NR_OF_BYTES其中 NR_OF_BYTES 小於服務器的 net_buffer_length -> 我認為這是最好的解決方案，雖然速度較慢，但​​不需要重新啟動服務器.

我使用了以下 mysqldump 命令： mysqldump --skip-comments --set-charset --default-character-set=utf8 --single-transaction --net-buffer_length 4096 DBX > dumpfile

Answer 13

請嘗試在編輯→首選項→SQL查詢中取消選中限制行

因為您應該將 mysql 配置文件中的 'interactive_timeout' 和 'wait_timeout' 屬性設置為您需要的值。

Answer 14

在 Edit->Preferences->SQL editor->MySQL session 中更改“讀取超時”時間

Answer 15

有時您的 SQL-Server 會陷入死鎖，我已經遇到這個問題 100 次了。 您可以重新啟動計算機/筆記本電腦以重新啟動服務器（簡單的方法），或者您可以轉到任務管理器>服務>您的服務器名稱（對我來說，它是 MySQL785 之類的東西）。 然后右鍵單擊>重新啟動。 再次嘗試執行查詢。

Answer 16

加載 .csv 文件時我遇到了同樣的問題。 將文件轉換為 .sql。

使用下面的命令，我設法解決了這個問題。

mysql -u <user> -p -D <DB name> < file.sql

希望這會有所幫助。

Answer 17

如果這里的所有其他解決方案都失敗了 - 檢查您的系統日志（/var/log/syslog 或類似的）以查看您的服務器在查詢期間是否內存不足。

在沒有配置交換文件的情況下將 innodb_buffer_pool_size 設置得太接近物理內存時會出現此問題。 MySQL 建議將特定於數據庫的服務器設置 innodb_buffer_pool_size 最大為物理內存的 80% 左右，我將其設置為 90% 左右，內核正在殺死 mysql 進程。 將 innodb_buffer_pool_size 移回 80% 左右，從而解決了問題。

Answer 18

我遇到了同樣的問題。 我相信當您有更大表的外鍵時會發生這種情況（這需要時間）。

我嘗試在沒有外鍵聲明的情況下再次運行 create table 語句，發現它有效。

然后在創建表后，我使用 ALTER TABLE 查詢添加了外鍵約束。

希望這會幫助某人。

Answer 19

這發生在我身上，因為我的 innodb_buffer_pool_size 設置為大於服務器上可用的 RAM 大小。 事情因此而中斷，並發出此錯誤。 修復方法是使用 innodb_buffer_pool_size 的正確設置更新 my.cnf。

Answer 20

轉到工作台編輯 → 首選項 → SQL 編輯器 → DBMS 連接讀取超時：最多 3000。錯誤不再發生。

Answer 21

去：

編輯 -> 首選項 -> SQL 編輯器

在那里您可以看到“MySQL Session”組中的三個字段，您現在可以在其中設置新的連接間隔（以秒為單位）。

Answer 22

原來我們的防火牆規則阻止了我與 MYSQL 的連接。 在解除防火牆策略以允許連接后，我能夠成功導入架構。

Answer 23

我遇到了同樣的問題 - 但對我來說，解決方案是權限太嚴格的數據庫用戶。 我必須允許mysql表上的Execute能力。 允許后，我不再斷開連接

Answer 24

首先檢查索引是否到位。

SELECT *
FROM INFORMATION_SCHEMA.STATISTICS
WHERE TABLE_SCHEMA = '<schema>'

Answer 25

我在運行一個存儲過程時遇到了這個問題——它在數據庫的一個表中創建了很多行。 我可以看到錯誤在時間越過 30 秒邊界后立即出現。

我嘗試了其他答案中的所有建議。 我相信其中一些幫助，但是 - 真正讓我工作的是從 Workbench 切換到 SequelPro。

我猜這是我在 Workbench 中找不到的一些客戶端連接。 也許這也會對其他人有所幫助？

Answer 26

如果您使用的是 SQL Work Bench，您可以嘗試使用索引，通過向表添加索引，添加索引，單擊表上的扳手（扳手）符號，它應該會打開表的設置，如下所示，單擊索引視圖，鍵入索引名稱並將類型設置為索引，在索引列中，選擇表中的主列。

對其他表上的其他主鍵執行相同的步驟。

Answer 27

對於那些使用 SSH 連接到他們的 MySQL 數據庫的人來說，這里似乎缺少一個答案。 您需要按照其他答案的建議檢查兩個不是 1 的地方：

工作台編輯 → 首選項 → SQL 編輯器 → DBMS

工作台編輯 → 首選項 → SSH → 超時

我的默認 SSH 超時設置得非常低，導致我的一些（但顯然不是全部）超時問題。 之后，不要忘記重新啟動 MySQL Workbench！

最后，可能值得聯系您的數據庫管理員並要求他們通過 my.conf + mysql restart 增加 mysql 本身中的 wait_timeout 和 interactive_timeout 屬性，或者如果無法重新啟動 mysql，則進行全局設置。

希望這可以幫助！

Answer 28

要遵循並確保以下三件事：

1. 多個查詢是否顯示連接丟失？
2. 你如何在 MySQL 中使用 set 查詢？
3. 如何同時刪除+更新查詢？

答案：

1. 總是嘗試刪除定義器，因為 MySQL 創建了自己的定義器，如果更新涉及多個表，請嘗試進行單個查詢，因為有時多個查詢顯示連接丟失
2. 如果條件不涉及 SET 值，則始終在頂部設置值，但在 DELETE 之后。
3. 如果兩個操作都在不同的表上執行，請先使用刪除然后更新

Answer 29

由於升級 Mysql 后出現問題，我收到此錯誤消息。 在我嘗試執行任何查詢后立即出現錯誤

檢查路徑/var/log/mysql (linux) 中的 mysql 錯誤日志文件

在我的情況下，將 Mysql 所有者重新分配給 Mysql 系統文件夾對我有用

chown -R mysql:mysql /var/lib/mysql

Answer 30

首先建立連接mysql --host=host.com --port=3306 -u username -p然后選擇你的數據庫use dbname然后 source 啞source C:\\dumpfile.sql 。 完成后\\q

Answer 31

我的觀察——

當您一起運行 MySQL Workbench 和終端並在終端中運行時 -

SET AUTOCOMMIT = 0;

或者

START TRANSACTION;

那么你通常會面臨這樣的問題。

甚至之后——

SET AUTOCOMMIT = 1;

或者

COMMIT;

問題依然存在。

您需要從終端和 MYSQL 工作台注銷，然后再次登錄或重新啟動。

Answer 32

檢查一下

OOM on /var/log/messages ,
modify innodb_buffer_pool_size value ; when load data , use 50% of os mem ; 

希望這可以幫助

Answer 33

這通常意味着您“與當前版本的 MySQL 服務器不兼容”，請參閱 mysql_upgrade。 我遇到了同樣的問題，只需要運行：

mysql_upgrade --password 文檔指出，“每次升級 MySQL 時都應執行 mysql_upgrade”。