MySQL - 単純なクエリで無限ループが発生し、取得される rows_fetched 数が増加することがあります。
P粉022140576
P粉022140576 2023-09-08 09:20:56
0
1
609

私は過去 4 週間、Docker Mysql Percona Distribution (percona:8.0.32-24、空の my.cnf) でクエリが断続的に永遠に実行される理由を解明しようと努めてきました。このポストスクリプト クエリは、MySQL Shell のデータ マイニング アルゴリズムを使用して生成された複数の CSV をインポートした後に実行されます。半分の時間は 2 ~ 3 秒で正常に実行されます。

そうしないと、正しい rows_inserted 数が表示されている場合でも、処理が停止して 無限ループ (2 日以上) に入り、rows_fetched (fig1.png) の数が増加し続けます。このクエリの実行にこれほど時間がかかるのはなぜですか?また、テーブルを際限なく読み取っている (rows_fetched が高い) のはなぜですか?

リーリー

** クエリを実行する前に 2 つの指標 (信頼性とサポート) を挿入します:

リーリー

INSERT を使用しない場合も同じ動作が観察されます。

説明文 (fig3.png) を参照してください。無限ループが発生すると、次のことが観察されます:

  • SHOW PROCESS LIST : クエリには status="executing" のマークが付けられています。

  • 表示エンジンの innodb ステータス: トランザクション セクションにクエリが見つかりません。

  • select * from sys.schema_table_statistics WHERE table_schema = 'DB_NAME' rows_fetched 出力は無限に増大するようです。 (fig1.png は機能しない、fig4.png は機能する、両方とも同じデータに対して実行されるを参照)。

どんな助けや洞察も、命を救う可能性があります。

P粉022140576
P粉022140576

全員に返信(1)
P粉645569197

PK の最後に を入力します:

リーリー

322 は 2 4*80 から来ていることに注意してください。これは、1 つの列のみを使用することを意味します。 (const についても同様です。)

  • 2バイト長フィールド
  • utf8mb4 文字あたり最大 4 バイト
  • 宣言には 80 文字が含まれています

これは、322 バイト全体が割り当てられることを意味するものではありませんが、これは「最悪のシナリオ」です。

いいねを押す +0
人気のチュートリアル
詳細>
最新のダウンロード
詳細>
ウェブエフェクト
公式サイト
サイト素材
フロントエンドテンプレート