2012-03-29 18 views
3

RoRアプリケーションのデータベースで大きなテーブルに問題があります。
表EVENTS:クエリ結果のソートが遅すぎる

create_table "events", :force => true do |t| 
    t.integer "id" 
    t.integer "device_id" 
    t.string "data_type" 
    t.integer "element_id" 
    t.t.datetime "created_at" 
end 

私はこのクエリによって、このテーブルのレコードを検索するときに問題がある:

SELECT SQL_NO_CACHE `events`.* FROM `events` 
WHERE `events`.`device_id` = N AND `events`.`data_type` = 'S' 
AND (`events`.`created_at` BETWEEN 'S' AND 'S') 
ORDER BY events.created_at DESC LIMIT 1 

私はその日の最後のイベントを取るので、注文したいですcreated_atで記録し、最初の要素を取得します。

あまりにも多くのコストをソートする操作が残念ですが、クエリが遅すぎます。

MySQLは、ソート順で行を取得する方法を調べるには、追加のパスを実行する必要があります。

Sorting result 7.1760s 7.2565s 1176 8080 0 0 
+4

'events.created_at'にインデックスがありますか? – beny23

+1

あなたはどのようなインデックスを持っていますか?索引はコストのソートに役立ちますが、必要な順序とWHERE句に適用するフィルタの両方を考慮する必要があります。 '(device_id、data_type、created_at DESC)'はここでは良いインデックスですが、このクエリに焦点を絞っています。 – MatBailie

+0

私は解決策を持っていた..... 私は、クエリを変更し、短い時間ウィンドウを作る必要があります! – Dabidi

答えて

0

おそらくデータを取得できるイベントのサマリーテーブルを維持できますか?トリガーを使用して集計し、サマリー表にデータを入力します。 EVENT_SUMMARYテーブルには最新の行または最新の行へのポインタが含まれているため、クエリで並べ替えを行う必要はありません。私はこれを約8000万行のテーブルでうまく動作させてくれました。

トリガーは余分な作業をしているため、挿入時にパフォーマンス上の問題を引き起こすことに注意してください。

要約テーブルがいくつあるかによって、サマリーテーブルが最適な方法ではない可能性があります。

どのくらいのデータがありますか?どのくらいの頻度で(ディスアグリゲータごとに)書き込まれますか?

+0

mmmを約2,000万行にすると非常に便利です。それは毎秒10〜15回書かれています.... – Dabidi

関連する問題