0

MySQL SELECT クエリが遅く、トラブルシューティングができないようです。

これは単純なもので、約 600,000 レコードのテーブル上にあります。

SELECT * 
FROM  `civicrm_contact` contact
WHERE contact.external_identifier =123456

Select クエリには 3 ～ 6 秒かかるため、このクエリに依存する別の 600,000 レコードをインポートすることはまったく現実的ではありません。

テーブル インデックスは、添付の画像に示されています。テーブル インデックス

contact.id=123456 に基づいて検索すると、クエリ時間は約 0.004 秒に短縮されます。contact.id はテーブルの主キーです。external_identifier は一意のインデックスです。

4

4 に答える 4

1

これが古いスレッドであることは承知していますが、CiviCRM に関連しているため、自分の考えを押し出すことにしました。コア パッケージ テーブルの 1 つを変更してクエリを高速に実行したため、この修正は実際にはベスト プラクティスではありません。これはあなたにとっては問題ないかもしれませんが、私はこれをすべての人に絶対にお勧めしません.

あなたのソリューションはおそらくクエリの問題を強調していますが、数値を期待していることをクエリに伝えているようですが、実際にはデータは VARCHAR として保存されています。それで、値を一重引用符で囲むだけでうまくいくと思いますか？

SELECT * FROM civicrm_contact連絡先 WHERE contact.external_identifier = '123456'

これがないと、暗黙のデータ型変換が行われるので、クエリで INDEX を使用できないと確信しています (長年 Oracle を使用してきました)。

説明計画は、この理論を証明する必要があります。

ありがとう

パルベス

于 2013-04-14T11:24:17.313 に答える
0

VARCHAR の代わりに INT 型の external_identifier を作成するように構造を変更しました。速度が 0.006 秒に増加しました

これがより広範な影響を与えるかどうかはまだわかりません

于 2012-04-24T18:07:09.053 に答える
0

データ型の変換が問題であることに疑いがあります。インデックス付きフィールドのサイズ制限くらいかな。btree であることは、インデックス キーがハッシュ キーよりもはるかに大きくなる可能性があることを意味します。これは必要ですか？外部 ID を別のテーブルに保存し、数値 ID に基づいてリンクする方がよいでしょうか?

ここでは、答えよりも多くの質問があります。

于 2013-06-04T14:47:58.520 に答える
0

BTREEインデックスを使用しているようです。<この列に対して ( 、>、<=またはを使用して) 範囲クエリを実行しない場合は>=、ハッシュ ベースのインデックスを使用することをお勧めします。

詳細については、B ツリー インデックスとハッシュ インデックスの比較を参照してください。

ここで正確な構文を参照してください。

于 2012-04-23T16:45:20.717 に答える