1

少し問題があります。と の 2 つのテーブルが eventsありmultimediaます。 events持っている

id, 
device_id
created_at field

主キーは id であり、device_idandcreated_atフィールドによって形成されたインデックスがあります。

multimediaテーブルには次のフィールドがあります。

id
device_id
created_at
data (this field is a blob field and contains a 20k string)

主キーは id であり、device_idandcreated_byフィールドによって形成されたインデックスがあります。

created_at問題は、データの前にあるレコードを削除したい場合です。

クエリ: 

DELETE FROM events WHERE device_id = #{dev[0]} 
AND created_at <= '#{mm_critical_time.to_s}'

大丈夫です。5秒か6秒deleteで記録。

クエリ 

DELETE FROM multimedia WHERE device_id = #{dev[0]} 
AND created_at <= '#{mm_critical_time.to_s}'

実行が開始され、決して終了しないという問題があります。

どうしたの？

4

3 に答える 3

2

おそらく、検索する列のインデックスを作成する必要があります。

CREATE INDEX device_created_index
ON multimedia (device_id, created_at);

クエリの最適化について詳しく知りたい場合は、EXPLAIN SELECT の使用に関するこちらの回答を参照してください:これらの mysql クエリを実行するより良い方法はありますか?

于 2012-04-24T07:52:24.697 に答える
0

多くの変数が関係しているため、ストーリー全体を知らなくても、リレーショナルデータベースのパフォーマンスの問題を解決するのは非常に単純です。

ただし、提供したデータについては、主キーとインデックスを削除して実行することをお勧めします。

CREATE UNIQUE CLUSTERED INDEX uc ON events (device_id, created_at);
CREATE UNIQUE CLUSTERED INDEX uc ON multimedia (device_id, created_at);

フィールドの一意性を強制する必要がある場合は、id各テーブルのこの列に1つの一意の非クラスター化インデックスを作成します（ただし、deleteコマンドの方が時間がかかります）。

CREATE UNIQUE INDEX ix_id ON events (id);
CREATE UNIQUE INDEX ix_id ON multimedia (id);
于 2012-04-24T14:04:44.613 に答える
0

条件の順序は重要です。データベースサーバーを教えてくれませんでしたが、少なくともOracleではそうなので、次のように逆にしてみてください

DELETE FROM multimedia WHERE 
created_at <= '#{mm_critical_time.to_s}' 
AND device_id = #{dev[0]}

または、最速の部分で内部クエリを使用します

DELETE FROM multimedia WHERE 
created_at <= '#{mm_critical_time.to_s}' 
AND device_id in (select device_id from multimedia where device_id = #{dev[0]})

また、ボトルネックがどこにあるかを把握できるように、低速なクエリを分割して、その部分の速度を常にテストしています。一部のプログラムでは、クエリにかかった時間を表示し、Ruby ではベンチマークを使用できます。テスト中に選択で削除を補うことができます。

だからテスト：

select * FROM multimedia WHERE created_at <= '#{mm_critical_time.to_s}'

と

select * from multimedia WHERE device_id = #{dev[0]}

成功..

于 2012-04-24T11:11:03.713 に答える