MySQL server has gone awayの原因と直し方｜2006

(2006, "MySQL server has gone away") は、アプリが MySQL に問い合わせを送ろうとしたとき、接続がすでに切れていたときのエラーです。 よくある原因は次の2つです。

同じ原因でも、クライアント（ドライバ）によって、エラーの番号が 2006・2013・1153・4031 と変わりました。 番号だけで原因を決めず、「何をしたときに出たか」で切り分けます。

確認環境：MySQL 8.0.46、PyMySQL 2.2.8、mysql-connector-python 26.7.0、SQLAlchemy 2.1.4、mysql コマンド（クライアント）で再現しました（確認日 2026年10月11日）。

原因① max_allowed_packet を超えるデータを送った

max_allowed_packet を 1MB にして、2MB の文字列を送りました。

MySQL のマニュアルでは、サーバーは大きすぎるパケットを受け取ると、クライアントに問題があるとみなして接続を閉じると説明されています。PyMySQL では、その結果が MySQL server has gone away として表示されました。

直し方

SHOW VARIABLES LIKE 'max_allowed_packet';     -- 確認環境の既定は 67108864（64MB）
SET GLOBAL max_allowed_packet = 134217728;    -- 128MB

確認環境では、SET GLOBAL のあとも、すでにつないでいた接続の @@session.max_allowed_packet は変わりませんでした。 アプリの接続（接続プール）をつなぎ直してから試します。

マニュアルでは、クライアント側の上限も上げる必要がある場合があると説明されています。クラウドの DB は、各サービスの設定の方法で変更します。

原因② wait_timeout より長く、接続を使わなかった

wait_timeout を 3 秒にして、接続してから 5 秒待ってから問い合わせました。

マニュアルでは、サーバーは既定で、何もしないまま 8 時間たった接続を閉じると説明されています（確認環境の wait_timeout も 28800 秒 ＝ 8 時間）。Web アプリを夜間そのままにし、朝の最初のアクセスでエラーになるのは、この形です。

4031 のメッセージには、wait_timeout が原因だと書かれています。 2006・2013 は、ほかの原因（サーバーの再起動・ネットワーク）でも出るので、出た時刻と、その前にどれだけ接続が使われていなかったかを確かめます。

直し方：接続プールで、使う前に確かめる

SQLAlchemy で、wait_timeout を 3 秒にして試しました。

engine = create_engine(url, pool_pre_ping=True)     # 使う前に接続を確かめる
# または
engine = create_engine(url, pool_recycle=3600)      # 1時間たった接続は作り直す

SQLAlchemy の公式ドキュメントでは、pool_recycle は、一定時間で接続を閉じる MySQL のようなデータベースに向いていると説明されています。 pool_recycle は wait_timeout より短い秒数にします。

どちらも、接続を取り出すときに確かめるだけです。 ドキュメントにも、トランザクションの途中で切れた接続には効かないとあります。長い処理の途中で切れた場合は、処理をやり直す仕組みが必要です。

PyMySQL だけで使う場合

conn.ping(reconnect=True)     # 切れていたら、つなぎ直す

確認環境では、ping(reconnect=True) のあと SELECT 1 が成功しました。ただし PyMySQL 2.2.8 では reconnect 引数は非推奨という警告（DeprecationWarning）が出ました（「再接続したいなら、新しい接続を作る」という内容）。新しく書くコードは、接続プールか、処理ごとに接続する形にします。

バッチ処理で起きやすい形

確認の手順（チェックリスト）

よくある質問

Q. Java（JDBC）の Communications link failure と同じ原因ですか。 A. wait_timeout で切れた接続を使う、という原因は同じことがあります。関連記事の「Communications link failureの原因と直し方｜MySQL」で扱っています。

Q. wait_timeout を大きくすれば解決しますか。 A. 切れにくくはなりますが、使われない接続がサーバーに残り続けます。アプリ側で、使う前に確かめる（pre_ping）か、時間がたった接続を作り直す（recycle）ほうが、サーバーの再起動やネットワークの切断にも対応できます。

まとめ

• 送ったデータが大きすぎる（max_allowed_packet）か、長く使わなかった（wait_timeout）のが主な原因
• クライアントによって、2006・2013・1153・4031 と番号が変わる
• 4031 は wait_timeout が原因とメッセージに書かれている
• SQLAlchemy は pool_pre_ping=True か pool_recycle で直った
• バッチは書く直前に接続、INSERT は小分けに

参考・出典

確認日はいずれも 2026年10月11日です。

• MySQL 8.0 Reference Manual「MySQL server has gone away」：https://dev.mysql.com/doc/refman/8.0/en/gone-away.html
• SQLAlchemy ドキュメント「Connection Pooling」：https://docs.sqlalchemy.org/en/20/core/pooling.html

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。