エラーコード：2013。クエリ中にMySQLサーバーへの接続が失われました
エラーコード：2013を取得しました。クエリ中にMySQLサーバーへの接続が失われました / MySQL Workbenchを使用してテーブルにインデックスを追加しようとしたときにエラーが発生しました。長いクエリを実行するたびに表示されることにも気付きました。
タイムアウト値を増やす方法はありますか？
MySQL WorkBenchの新しいバージョンには、特定のタイムアウトを変更するオプションがあります。
私にとっては、編集→設定→SQLエディター→DBMS接続読み取りタイムアウト（秒）の下にありました：600
値を6000に変更しました。
データセット全体を検索するたびに制限を設定するため、チェックされていない制限行も面倒です。
クエリにBLOBデータがある場合、この回答で提案されているようにmy.ini change を適用することでこの問題を解決できます 。
[mysqld]
max_allowed_packet=16M
デフォルトでは、これは1Mになります（許容最大値は1024Mです）。指定された値が1024Kの倍数ではない場合、自動的に最も近い1024Kの倍数に丸められます。
参照されているスレッドはMySQLエラー 2006 に関するものですが、max_allowed_packetを1Mから16Mに設定します did 長いクエリを実行したときに私に現れた2013エラーを修正しました。
WAMPユーザーの場合：[wampmysqld]セクションにフラグがあります。
以下を/ 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
SET @@local.net_read_timeout=360;
警告：あなたがリモート接続でそれを適用しているとき、以下は働きません：
SET @@global.net_read_timeout=360;
このエラーメッセージには3つの原因が考えられます。
- 通常、ネットワーク接続の問題を示しているため、このエラーが頻繁に発生する場合はネットワークの状態を確認してください。
- 「クエリ中」フォームは、1つ以上のクエリの一部として何百万もの行が送信されているときに発生することがあります。
- ごくまれに、クライアントがサーバーへの初期接続を試みているときに発生する可能性があります。
詳細については を読んでください -
原因2：
SET GLOBAL interactive_timeout=60;
デフォルトの30秒から60秒以上まで
原因3：
SET GLOBAL connect_timeout=60;
Mysql設定ファイルの 'interactive_timeout'および 'wait_timeout'プロパティを必要な値に設定する必要があります。
ありがとうございます。しかし、mysqldbのアップデートによりconfigureは次のようになりました。
max_allowed_packet
net_write_timeout
net_read_timeout
performance_schema、information_schemaなど、MySQLの適切な機能に必要な多くのテーブルの再構築とともに、innoDBエンジンを再構築するMySQLのアップグレードを実行するだけです。
シェルから以下のコマンドを発行してください。
Sudo mysql_upgrade -u root -p
私はその古さを知っているが、Mac上で
1. Control-click your connection and choose Connection Properties.
2. Under Advanced tab, set the Socket Timeout (sec) to a larger value.
「編集」 - >「設定」 - >「SQLエディター」 - >「MySQL」セッションで「読み取りタイムアウト」時間を変更する
[編集]→[設定]→[SQLクエリ]で[制限行数]のチェックを外してください。
mysql設定ファイルの 'interactive_timeout'および 'wait_timeout'プロパティを必要な値に設定する必要があるためです。
あなたが大きなダンプファイルの復元中にこの問題に遭遇し、それが私の解決策が役に立つよりもネットワークと関係があるという問題（例えばlocalhostでの実行）を除外できる場合。
私のmysqldumpはmysqlが計算するには大きすぎるINSERTを少なくとも1つ持っていました。 mysql-cliの中にshow variables like "net_buffer_length";とタイプすれば、この変数を見ることができます。 3つの可能性があります。
- mysql内でnet_buffer_lengthを増やす - >これはサーバの再起動を必要とするでしょう
- 挿入ごとに1行が使用されますが、
--skip-extended-insertでダンプを作成します。 - >これらのダンプは読みやすくなりますが、1GBを超える大きなダンプには適していません。 - 拡張挿入（デフォルト）でダンプを作成しますが、net-buffer_lengthを制限します。 NR_OF_BYTESがサーバのnet_buffer_lengthよりも小さい
--net-buffer_length NR_OF_BYTESの場合 - >サーバの再起動を遅くする必要はありませんが、これが最良の解決策だと思います。
私は以下のmysqldumpコマンドを使用しました：mysqldump --skip-comments --set-charset --default-character-set=utf8 --single-transaction --net-buffer_length 4096 DBX > dumpfile
ここで他のすべての解決策が失敗した場合 - syslog（/ var/log/syslogまたは類似のもの）を調べて、クエリ中にサーバのメモリが不足していないか確認してください。
スワップファイルが設定されていない状態でinnodb_buffer_pool_sizeが物理メモリに近すぎるように設定されていると、この問題が発生しました。 MySQLは、データベース固有のサーバー設定innodb_buffer_pool_sizeを最大約80％の物理メモリに設定することを推奨します 、私はそれを約90％に設定していました。 innodb_buffer_pool_sizeを約80％に戻し、これで問題は解決しました。
.csvファイルをロードしたときに同じ問題が発生しました。ファイルを.sqlに変換しました。
下記のコマンドを使用して、私はこの問題を回避することができます。
mysql -u <user> -p -D <DB name> < file.sql
これが役立つことを願っています。
私はこれと同じ問題に直面しました。大きなテーブルへの外部キーがあると（時間がかかります）それが起こると思います。
外部キーを宣言せずにcreate table文を再度実行しようとしましたが、うまくいくことがわかりました。
それからテーブルを作成した後、ALTER TABLEクエリを使用して外部キー制約を追加しました。
これが誰かに役立つことを願っています。
Innodb_buffer_pool_sizeがサーバーで利用可能なRAMサイズより大きく設定されていたので、これは私に起こりました。物事はこれのために中断されていました、そしてそれはこのエラーを発行します。修正は、innodb_buffer_pool_sizeの正しい設定でmy.cnfを更新することです。
SQL Work Benchを使用している場合は、テーブルにインデックスを追加するには、インデックスを使用してください。インデックスを追加するには、テーブルのレンチ（スパナ）記号をクリックしてください。 、インデックスビューをクリックし、インデックス名を入力してタイプをindexに設定します。インデックス列で、テーブルの主列を選択します。
他のテーブルの他の主キーについても同じ手順を実行します。
データベース内のテーブルに大量の行を作成していたストアドプロシージャを実行しているときに、私はこれに遭遇しました。時間が30秒の境界を超えた直後にエラーが発生するのがわかりました。
私は他の答えですべての提案を試みました。私はそれのいくつかが助けになると確信しています、しかし - 私にとって本当にそれがうまくいったのはWorkbenchからSequelProに切り替えることでした。
私はそれが私がWorkbenchで見つけることができなかったことがクライアント側接続だったと思います。多分これは他の誰かにも役立つでしょうか？
ワークベンチに移動編集→設定→SQLエディタ→DBMS接続読み取りタイムアウト：最大3000。エラーは発生しなくなりました。
私たちのファイアーウォールのルールが私のMYSQLへの接続をブロックしていたことがわかりました。接続を許可するためにファイアウォールポリシーが解除された後、スキーマを正常にインポートできました。
私は同じ問題を抱えていました - しかし私にとって解決策は厳しすぎるパーミッションを持つDBユーザーでした。 Executeテーブルでmysql能力を許可する必要がありました。それを許可した後、私はもう接続を落とすことができませんでした
インデックス が最初に配置されているか確認してください。
SELECT *
FROM INFORMATION_SCHEMA.STATISTICS
WHERE TABLE_SCHEMA = '<schema>'
に行きなさい：
編集 - >設定 - > SQLエディタ
そこには、 "MySQL Session"グループの3つのフィールドがあります。ここで新しい接続間隔（秒単位）を設定できます。
SSHを使って自分のMySQLデータベースに接続している人には、ここで答えが欠けているようです。あなたは他の答えによって示唆されるように1ではない2つの場所をチェックする必要があります：
ワークベンチ編集→設定→SQLエディタ→DBMS
ワークベンチ編集→設定→SSH→タイムアウト
私のデフォルトのSSHタイムアウトは非常に低く設定されており、私のタイムアウトの問題のいくつか（しかし明らかにすべてではない）を引き起こしていました。その後、MySQL Workbenchを再起動することを忘れないでください。
最後に、DB管理者に連絡して、my.conf + mysql restartを介してmysql自体のwait_timeoutおよびinteractive_timeoutプロパティを増やすように依頼するか、mysqlの再起動が選択肢でない場合はグローバルセットを実行することをお勧めします。
お役に立てれば！