350

エラーコード：2013を取得しました。MySQLWorkbenchを使用してテーブルにインデックスを追加しようとすると、クエリエラー中にMySQLサーバーへの接続が失われました。長いクエリを実行するたびに表示されることにも気づきました。

タイムアウト値を増やす方法はありますか？

4

32 に答える 32

650

MySQL WorkBenchの新しいバージョンには、特定のタイムアウトを変更するオプションがあります。

私にとっては、[編集]→[設定]→[SQLエディター]→[DBMS接続の読み取りタイムアウト（秒単位）]の下にありました：600

値を6000に変更しました。

また、データセット全体を検索するたびに制限を設定するので、制限行のチェックを外すのは面倒です。

于 2012-10-08T22:49:13.540 に答える
47

クエリにBLOBデータがある場合、この回答で提案されてmy.iniいるように変更を適用することで、この問題を修正できます。

[mysqld]
max_allowed_packet=16M

デフォルトでは、これは1Mになります（許可される最大値は1024Mです）。指定された値が1024Kの倍数でない場合は、1024Kの最も近い倍数に自動的に丸められます。

参照されているスレッドはMySQLエラー2006max_allowed_packetに関するものですが、1Mから16Mに設定すると、長いクエリを実行したときに表示された2013エラーが修正されました。

WAMPユーザーの場合：[wampmysqld]セクションにフラグがあります。

于 2014-07-03T13:36:36.647 に答える
39

comandlineオプションnet_read_timeout/wait_timeoutと適切な値（秒単位）を使用してDBサーバーを起動します-例：--net_read_timeout=100。

参考までに、こことここを参照してください。

于 2012-05-12T12:17:27.523 に答える
17

以下を/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
于 2015-04-17T15:11:36.287 に答える
17 
SET @@local.net_read_timeout=360;

警告：リモート接続で適用する場合、以下は機能しません。

SET @@global.net_read_timeout=360;

編集： 360は秒数です

于 2015-04-20T03:58:19.997 に答える
10

mysql構成ファイルの「interactive_timeout」および「wait_timeout」プロパティを必要な値に設定する必要があります。

于 2012-05-12T12:19:04.527 に答える
10

このエラーメッセージには3つの原因が考えられます

  1. 通常、これはネットワーク接続の問題を示しており、このエラーが頻繁に発生する場合は、ネットワークの状態を確認する必要があります
  2. 「クエリ中」フォームは、1つ以上のクエリの一部として数百万行が送信されている場合に発生することがあります。
  3. ごくまれに、クライアントがサーバーへの初期接続を試みているときに発生する可能性があります

詳細について は>>をお読みください

原因2：

SET GLOBAL interactive_timeout=60;

デフォルトの30秒から60秒以上

原因3：

SET GLOBAL connect_timeout=60;
于 2016-12-08T06:30:24.940 に答える
10

私の場合、接続タイムアウト間隔を6000以上に設定しても機能しませんでした。

私はワークベンチが私にできると言っていることをしただけです。

クエリがDBMSからデータを返すのにかかる最大時間。読み取りタイムアウトをスキップするには、0を設定します。

Macの設定->SQLエディタ->MySQLセッションに移動->接続読み取りタイムアウト間隔を0に設定します。

そしてそれは動作します

于 2019-11-26T03:55:28.580 に答える
7

MySQLのアップグレードを実行するだけで、innoDBエンジンが再構築され、MySQLが正しく機能するために必要な多くのテーブルperformance_schema（、information_schemaなど）が再構築されます。

シェルから次のコマンドを発行します。

sudo mysql_upgrade -u root -p
于 2014-05-19T20:16:38.563 に答える
6

私はその古いことを知っていますが、マックで

1. Control-click your connection and choose Connection Properties.
2. Under Advanced tab, set the Socket Timeout (sec) to a larger value.
于 2015-03-27T06:53:45.880 に答える
6

大きなダンプファイルの復元中にこの問題が発生し、それがネットワーク（ローカルホストでの実行など）に関係しているという問題を除外できる場合は、私の解決策が役立つ可能性があります。

私のmysqldumpは、mysqlが計算するには大きすぎるINSERTを少なくとも1つ保持していました。show variables like "net_buffer_length";mysql-cli内に入力すると、この変数を表示できます。3つの可能性があります。

  • mysql内のnet_buffer_lengthを増やします->これにはサーバーの再起動が必要になります
  • でダンプを作成し--skip-extended-insert、挿入ごとに1行を使用します->これらのダンプは読みやすくなりますが、非常に低速になる傾向があるため、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

于 2016-01-08T11:07:27.267 に答える
5

SQL-Serverがデッドロックに陥ることがありますが、私は100回ほどこの問題に直面しています。コンピューター/ラップトップを再起動してサーバーを再起動するか（簡単な方法）、タスクマネージャー>サービス> YOUR-SERVER-NAMEに移動できます（私にとっては、MySQL785のようなものでした）。そして、右クリック>再起動します。クエリの実行を再試行してください。

于 2021-02-10T13:28:46.993 に答える
4

[編集]→[設定]→[SQLクエリ]で行の制限をオフにしてみてください

mysql構成ファイルの「interactive_timeout」および「wait_timeout」プロパティを必要な値に設定する必要があるためです。

于 2014-07-24T09:59:29.290 に答える
4

[編集]->[設定]->[SQLエディター]->[MySQLセッション]で「読み取りタイムアウト」時間を変更します

于 2016-04-21T09:25:34.317 に答える
2

.csvファイルをロードするときに同じ問題が発生しました。ファイルを.sqlに変換しました。

以下のコマンドを使用して、この問題を回避することができます。

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

これがお役に立てば幸いです。

于 2016-09-08T06:19:47.260 に答える
2

ここにある他のすべての解決策が失敗した場合は、syslog（/ var / log / syslogなど）をチェックして、クエリ中にサーバーのメモリが不足していないかどうかを確認します。

この問題は、スワップファイルが構成されていない状態でinnodb_buffer_pool_sizeが物理メモリに近すぎるように設定されている場合に発生しました。MySQLは、データベース固有のサーバー設定innodb_buffer_pool_sizeを物理メモリの最大約80％に設定することをお勧めします。これを約90％に設定すると、カーネルがmysqlプロセスを強制終了していました。innodb_buffer_pool_sizeを約80％に戻し、問題を修正しました。

于 2017-01-05T18:46:38.710 に答える
2

ワークベンチ編集→設定→SQLエディタ→DBMS接続読み取りタイムアウト：最大3000に移動します。エラーは発生しなくなりました。

于 2018-09-01T02:50:16.443 に答える
1

私はこれと同じ問題に直面しました。より大きなテーブルへの外部キーがある場合に発生すると思います（時間がかかります）。

外部キー宣言なしでcreatetableステートメントを再度実行しようとしましたが、機能することがわかりました。

次に、テーブルを作成した後、ALTERTABLEクエリを使用して外部キー制約を追加しました。

これが誰かを助けることを願っています。

于 2016-12-23T07:22:30.237 に答える
1

これは、私のinnodb_buffer_pool_sizeがサーバーで使用可能なRAMサイズよりも大きく設定されていたために発生しました。これが原因で処理が中断され、このエラーが発生します。修正は、my.cnfをinnodb_buffer_pool_sizeの正しい設定で更新することです。

于 2017-02-26T15:35:04.390 に答える
1

移動：

編集->設定->SQLエディター

そこで、「MySQLセッション」グループに3つのフィールドが表示され、新しい接続間隔（秒単位）を設定できるようになりました。

于 2017-05-05T13:23:47.980 に答える
0

ファイアウォールルールがMYSQLへの接続をブロックしていたことが判明しました。接続を許可するためにファイアウォールポリシーが解除された後、スキーマを正常にインポートできました。

于 2017-05-11T15:38:48.740 に答える
0

私も同じ問題を抱えていましたが、私にとっての解決策は、権限が厳しすぎるDBユーザーでした。私はテーブルのExecute上の能力を許可しなければなりませんでした。mysqlそれを許可した後、私はもう接続を切断しませんでした

于 2017-08-31T17:35:43.897 に答える
0

インデックスが最初に配置されているかどうかを確認します。

SELECT *
FROM INFORMATION_SCHEMA.STATISTICS
WHERE TABLE_SCHEMA = '<schema>'
于 2017-09-22T03:58:20.037 に答える
0

データベース内のテーブルに大量の行を作成していたストアドプロシージャを実行しているときに、これに遭遇しました。時間が30秒の境界を超えた直後にエラーが発生するのを見ることができました。

私は他の答えのすべての提案を試しました。確かにその一部は役に立ったと思いますが、実際に機能したのは、WorkbenchからSequelProに切り替えたことです。

Workbenchで見つけられなかったのはクライアント側の接続だったと思います。多分これは他の誰かにも役立つでしょうか？

于 2017-12-19T21:19:35.317 に答える
0

SQL Work Benchを使用している場合は、インデックスを使用して、テーブルにインデックスを追加し、インデックスを追加して、テーブルのレンチ（スパナ）記号をクリックすると、以下のテーブルのセットアップが開きます。 、インデックスビューをクリックし、インデックス名を入力して、タイプをインデックスに設定します。インデックス列で、テーブルのプライマリ列を選択します。

他のテーブルの他の主キーに対しても同じ手順を実行します。

于 2018-06-25T08:21:39.950 に答える
0

SSHを使用してMySQLデータベースに接続している人にとっては、ここに答えが欠けているようです。他の回答で示唆されているように、1つではなく2つの場所をチェックする必要があります。

ワークベンチ編集→設定→SQLエディタ→DBMS

ワークベンチ編集→設定→SSH→タイムアウト

デフォルトのSSHタイムアウトが非常に低く設定されていたため、タイムアウトの問題の一部（すべてではないようです）が発生しました。その後、MySQLWorkbenchを再起動することを忘れないでください！

最後に、DB管理者に連絡して、my.conf + mysqlrestartを介してmysql自体のwait_timeoutおよびinteractive_timeoutプロパティを増やすように依頼するか、mysqlの再起動がオプションでない場合はグローバルセットを実行することをお勧めします。

お役に立てれば！

于 2019-05-06T17:36:16.490 に答える
0

従うべき3つのことと確認すること：

  1. 複数のクエリで接続が失われたことが示されるかどうか。
  2. MySQLでsetqueryをどのように使用しますか？
  3. クエリの削除と更新を同時に行う方法は？

回答：

  1. MySQLは独自の定義者を作成するため、常に定義者を削除してみてください。更新に関係する複数のテーブルが単一のクエリを作成しようとする場合は、複数のクエリで接続が失われることがあります。
  2. 常に先頭にSET値がありますが、条件にSET値が含まれていない場合はDELETEの後になります。
  3. 両方の操作が異なるテーブルで実行される場合は、最初に削除してから更新を使用します
于 2019-09-22T16:10:49.680 に答える
0

Mysqlのアップグレード後の問題が原因で、このエラーメッセージが表示されました。クエリを実行しようとした直後にエラーが表示されました

パス内のmysqlエラーログファイルを確認します/var/log/mysql（Linux）

私の場合、Mysqlの所有者をMysqlシステムフォルダに再割り当てすることでうまくいきました

chown -R mysql:mysql /var/lib/mysql
于 2021-01-23T19:29:54.200 に答える
0

最初に接続を確立 mysql --host=host.com --port=3306 -u username -p してから、データベースを選択し、use dbname 次にソースダムを選択しますsource C:\dumpfile.sql。それが終わった後\q

于 2021-10-29T05:32:48.833 に答える
0

私の観察-

MySQL Workbenchとターミナルを一緒に実行すると、ターミナルで実行します-

SET AUTOCOMMIT = 0;

また

START TRANSACTION;

次に、通常、この種の問題に直面します。

そしてその後も-

SET AUTOCOMMIT = 1;

また

COMMIT;

問題は解決しません。

ターミナルとMYSQLワークベンチの両方からログアウトしてから再度ログインするか、再起動する必要があります。

于 2021-11-26T07:13:23.350 に答える
-1

について確認する

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

お役に立てれば

于 2016-07-21T04:30:16.290 に答える
-1

これは通常、「MySQLサーバーの現在のバージョンとの非互換性」があることを意味します。mysql_upgradeを参照してください。私はこれと同じ問題に遭遇し、単に実行する必要がありました：

mysql_upgrade --passwordドキュメントには、「MySQLをアップグレードするたびにmysql_upgradeを実行する必要がある」と記載されています。

于 2016-08-03T10:34:55.490 に答える