5

クエリに問題があり、実行に 17 秒かかりました (350k 行)。

SELECT idgps_unit, MAX(dt) 
         FROM gps_unit_location
        GROUP BY 1

説明

1   SIMPLE  gps_unit_location   index       fk_gps2 5       422633

遊んだ後、1​​秒かかるこのソリューションを思いつきました：

Select idgps_unit, MAX(dt) from (
SELECT idgps_unit,  dt
         FROM gps_unit_location
) d1
Group by 1

説明：

1   PRIMARY <derived2>  ALL                 423344  Using temporary; Using filesort
2   DERIVED gps_unit_location   index       gps_unit_location_dt_gpsid  10      422617  Using index

そして今、私は混乱しています.なぜクエリ＃2が速いのに、クエリ＃1は同じクエリのようで、より効率的に書かれているようです.

Index1:DT、Index2:idgps_unit、Index3:idgps_unit+DT

実行時間は一貫しています。クエリ #1 は常に 17 ～ 19 秒かかります。#1 <1秒の間。

Godaddy VPS Windows Server 2008 エコノミーを使用しています

テーブルの例:

id | idgps_unit | dt | location
1 | 1 | 2012-01-01 | 1
2 | 1 | 2012-01-02 | 2
3 | 2 | 2012-01-03 | 3
4 | 2 | 2012-01-04 | 4
5 | 3 | 2012-01-05 | 5
4

2 に答える 2

1

インデックスが適切に設定されていないと思います.2番目のクエリは、意味がある場合は独自の内部インデックスグループを効果的に作成している一種の内部クエリです!

于 2013-02-19T17:11:57.987 に答える
1

gps_unit_locationまず、は実際にはビューではなくテーブルであると想定しています。第二に、両方のクエリを複数回実行したことも想定しているため、キャッシュは説明ではありません。(キャッシュとは、最初のクエリを実行し、テーブルをページ キャッシュにロードし、2 番目にディスクではなくメモリから読み取ることです。)

のインデックスはありgps_unit_location(idgps_unit)ますか? レコードは非常に広いですか？これらの質問に対する答えが「はい」の場合、次のことが起こっている可能性があります。

もしそうなら、あなたは索引付けに関して興味深い問題を抱えているかもしれません。インデックスがそのようなクエリを高速化すると考えるでしょう。ただし、それが行うことは、値をidgps_id順番に検索することです。インデックスに日付が含まれていない場合、データベースは各ページからデータをフェッチする必要があります。テーブルがメモリに収まらない場合、多くの場合、キャッシュ ミス、つまりページをロードする時間が発生します。

対照的に、テーブルの幅が広く、エンジンが完全なテーブル スキャンを実行する場合は、テーブルを高速で処理して、対象の 2 つのフィールドを抽出できます。それはそれらを横に置きます。テーブル全体に比べてサイズが小さい場合、それらの並べ替えにはほとんど時間がかかりません。ほら、クエリはより速く終了します。

私の推測では、2 番目の構造ではインデックスの使用が削除されます。

ちなみに、インデックスを に変更することでこれを修正できますgps_unit_location(idgps_unit, dt)。フィールドをインデックスに含めることにより、クエリでデータを読み込む必要がなくなります。

于 2013-02-19T17:18:07.530 に答える