快捷導(dǎo)航

MySQL 表新增字段時(shí)報(bào)丟失連接錯(cuò)誤

更新時(shí)間：2026年01月25日 14:31:28 作者：一線大碼

MySQL在新增字段時(shí)遇到"Lost connection to MySQL server during query"錯(cuò)誤,可能由于網(wǎng)絡(luò)問(wèn)題、查詢超時(shí)或內(nèi)存不足等原因,下面就來(lái)詳細(xì)的介紹一下該問(wèn)題的解決,感興趣的可以了解一下

1. 問(wèn)題描述

有一張MySQL數(shù)據(jù)庫(kù)表，業(yè)務(wù)變動(dòng)，需要新增一個(gè)業(yè)務(wù)字段，于是直接用下面的SQL語(yǔ)句進(jìn)行字段新增：

ALTER TABLE table_name ADD `add_field` tinyint(1) DEFAULT NULL COMMENT '新增字段';

使用Navicat for MySQL執(zhí)行該語(yǔ)句會(huì)報(bào)一個(gè)錯(cuò)誤，如下圖所示：

2013 - Lost connection to MySQL server during query，翻譯過(guò)來(lái)就是在查詢過(guò)程中，MySQL服務(wù)器失去連接。

該問(wèn)題是大約一年前遇到的（2020年我寫(xiě)的文章），最近整理筆記看到了，趁有時(shí)間做一些整理記錄。但是當(dāng)時(shí)的具體環(huán)境已經(jīng)無(wú)法復(fù)現(xiàn)了。

2. 官方文檔

MySQL 官方文檔的附錄中有一篇是講 MySQL 服務(wù)器連接斷開(kāi)。下面是我翻譯的內(nèi)容：

此錯(cuò)誤消息有三個(gè)可能的原因。

通常它表示網(wǎng)絡(luò)連接有問(wèn)題，如果這個(gè)錯(cuò)誤經(jīng)常發(fā)生，你應(yīng)該檢查一下你的網(wǎng)絡(luò)狀況。如果提示的錯(cuò)誤消息包含"during query"字符，那么您遇到的情況可能就是這種原因。

有時(shí)，當(dāng)幾百萬(wàn)行作為一個(gè)或多個(gè)查詢的一部分被發(fā)送時(shí)，就會(huì)發(fā)生"during query"表單。如果您知道發(fā)生了這種情況，那么您應(yīng)該嘗試將net_read_timeout從默認(rèn)的30秒增加到60秒或足以完成數(shù)據(jù)傳輸?shù)母L(zhǎng)時(shí)間。

更少見(jiàn)的情況是，當(dāng)客戶端試圖初始化連接到服務(wù)器時(shí)，會(huì)發(fā)生這種情況。在這種情況下，如果connect_timeout值被設(shè)置為幾秒，那么您可以通過(guò)將其增加到10秒來(lái)解決問(wèn)題，如果您的連接距離很長(zhǎng)或速度較慢，那么時(shí)間可能會(huì)更長(zhǎng)。你可以通過(guò)查詢Aborted_connects來(lái)確定你是否正在經(jīng)歷這種更不常見(jiàn)的原因。服務(wù)器每中止一個(gè)初始連接嘗試，它的值就會(huì)增加1。如果錯(cuò)誤消息包括"reading authorization packet"，表明這正是您所需要的解決方案。

SHOW GLOBAL STATUS LIKE 'Aborted_connects'

如果原因不是以上所述的，你可能遇到了BLOB值大于max_allowed_packet的問(wèn)題，這可能導(dǎo)致某些客戶端出現(xiàn)此錯(cuò)誤。有時(shí)你可能還會(huì)看到一個(gè)ER_NET_PACKET_TOO_LARGE錯(cuò)誤，可以確定是需要提高max_allowed_packet值了。

SHOW VARIABLES LIKE '%max_allowed_packet%';

3. 解決辦法

通過(guò)查閱官方文檔，不難看出其實(shí)比較符合第一條解釋。結(jié)合當(dāng)時(shí)那家公司的網(wǎng)絡(luò)，確實(shí)經(jīng)常的時(shí)斷時(shí)續(xù)的，網(wǎng)絡(luò)環(huán)境比較差。

MySQL的這個(gè)錯(cuò)誤除了官方說(shuō)的幾種情況，還需要針對(duì)自己的業(yè)務(wù)場(chǎng)景進(jìn)行適當(dāng)探索和甄別，具體情況具體分析。這里再記錄一下另一種可能，因?yàn)?code>ALTER TABLE操作是比較耗時(shí)的，所以也很有可能是因?yàn)槌瑫r(shí)原因報(bào)的錯(cuò)誤。查詢關(guān)于超時(shí)時(shí)間的系統(tǒng)變量：

SHOW VARIABLES LIKE '%timeout%';

高性能MySQL這本書(shū)的第四章Schema與數(shù)據(jù)優(yōu)化提到了以下內(nèi)容：

MySQL的ALTER TABLE操作的性能對(duì)大表來(lái)說(shuō)是個(gè)問(wèn)題。MySQL執(zhí)行大部分修改表結(jié)構(gòu)操作的方法是用新的結(jié)構(gòu)創(chuàng)建一個(gè)空表，從舊表中查出所有數(shù)據(jù)插入新表，然后刪除舊表。這樣操作可能需要花費(fèi)很長(zhǎng)時(shí)間，如果內(nèi)存不足表又很大，而且還有很多索引的情況下尤其如此。

一般而言，大部分ALTER TABLE操作將導(dǎo)致MySQL服務(wù)中斷。對(duì)于常見(jiàn)場(chǎng)景，能使用的技巧只有兩種：一種是先在一臺(tái)不提供服務(wù)的機(jī)器上執(zhí)行ALTER TABLE操作，然后和提供服務(wù)的主庫(kù)進(jìn)行切換；另一種技巧是影子拷貝，就是用要求的表結(jié)構(gòu)創(chuàng)建一張與源表無(wú)關(guān)的新表，然后通過(guò)重命名和刪表操作交換兩張表。