0

だから私はこのクエリを実行するのに苦労しています。本当に長い時間がかかります。
そのMySQL Innodb。私が使用しているフィールドにはインデックスが付けられています。innodbプール構成に約10ギガが割り当てられたかなり強力なサーバー上にあります。

UPDATE TEMP_account_product p
JOIN products_temp c ON (c.`some_id` = p.`old_someid`)
SET p.`product` = c.id
WHERE p.product IS NULL;

ここで注意すべきことは、両方のテーブルに約 900,000 行が含まれていることです。この行は約 800,000 レコードを返します ( WHERE p.product IS NULL;)

私はここでちょっとうんざりしているように感じますが、とにかくやってみようと思いました.

4

2 に答える 2

0

バッチで実行することをお勧めします。これにより、クエリプランに依存して、更新を開始する前に結果セット全体をメモリに入れないようにする必要がなくなります。クエリにLIMIT1000のようなものを追加し、影響を受ける行の数がゼロになるまで実行します（手法は環境によって異なりますが、SQLで実行できると思います）。

更新、これは（現状のままで）有効なオプションではありません。

案の定、私はUPDATEドキュメントでこれを見落としていました：

複数テーブル構文の場合...この場合、ORDERBYとLIMITは使用できません。

于 2012-08-10T14:37:16.237 に答える
0

このようなタイプのリクエストの実行が遅くなる理由として、次のことが考えられると思います。

  • 最も可能性が高い- 更新されたフィールドに INDEX(es) があり、そのリクエストは多くの行を更新しています。その場合、MySQL は UPDATE 中にその INDEX(es) を再構築する多くの作業を行う必要があります。その場合、リクエストの前にINDEXを削除し、後で再作成します（必要な場合）。
  • JOIN は遅いです (その JOIN で選択することで確認できます)。つまり、結合は INDEXES なしで行われます。その場合はインデックスを追加してください。
  • WHERE のフィルタリングが遅い (つまり、MySQL がフル スキャンを実行してフィルタリングする) - 同じフィルターで選択することで、その速度を確認できます。
于 2012-08-10T14:49:41.897 に答える