2011-01-15 14 views
0

私は何か問題を引き起こしているクエリがあります。私はこのSQLを書く良い方法があるのだろうかと思っています。遅いSQLクエリ - 日付間隔に応じてデータを選択します。

SELECT * FROM report 
WHERE blogid = 1769577 
     AND DATE_SUB(CURDATE(),INTERVAL 30 DAY) <= datetime 

したがって、結果がより高速に取得されます。

ありがとうございます。

+0

30日以上経過した特定のブログの情報を選択しているとします。 datetime列にはSQL datetime値としてデータが格納されます。右? – farzad

+0

むしろ、データの有効期限が30日未満* – ktm5124

+0

これは、レポートデータを格納する別のテーブルではありません。 id、blogid、report_type(int)、およびdatetimeが含まれます。基本的にブログが表示されるたびに、レコードがこのテーブルに挿入されます。 – gus

答えて

2

あなたのテーブルが巨大である場合、あなたは大きなを持つことができ、水平パーティショニングを考慮するかもしれない

を私は、クエリに何か問題が表示されていないが、あなたはのblogidのインデックスを持っていることを確認してください可能性があり、日時列パフォーマンスへの影響http://dev.mysql.com/tech-resources/articles/performance-partitioning.html

+0

クエリは遅い以外は正常に動作します。結果を得るのに4秒以上かかると、テーブルには17万レコードしかありませんか?日時は、blogidのように索引付けされます。 – gus

+0

@gus、ブログIDとdatetimeに別々のインデックスがある場合、mysqlはインデックスのうちの1つだけを使用できます。このクエリでは、複合インデックス(blogid、datetime)を使用できます。パフォーマンスが少し向上するかもしれません。 –

+0

はい、それもやってみてください。ありがとう – gus

0

Oracle SQLでは、+/-演算子を使用して日付演算を行うことができます。私はそれがMySQLで動作するかどうかは分かりませんが、datetime> =(CURDATE() - 30)を試してみることもできます。

SELECT * FROM report WHERE blogid = 1769577 AND datetime >= (curdate() - 30) 

編集:このブログのエントリは私の提案を確認しているようだ:http://mysql-tips.blogspot.com/2005/04/mysql-date-calculations.html

+0

私はAND datetime> =(CURDATE() - INTERVAL 30 DAY)を使用できると思います。 – gus

0

私は内部DATEDIFF()関数を使用して、代わりの間隔を引く示唆しています。このように:

datediff(curdate(), datetime) < 30 

ので、クエリは次のとおりです。

SELECT * FROM report WHERE blogid = 1769577 AND datediff(curdate(), datetime) < 30 
+4

WHERE句のフィールドに関数を適用すると、そのフィールドのインデックスは使用できなくなります。従ってdatetime>(currtime - 30)は(currtime - datetime)<30. –

+0

よりも良いかもしれません。私はそれを考慮していませんでした。ありがとう。 – farzad

0

推測1:あなたのblogidint列ではありません。次に、MySQLのマニュアルを読むことができます: 変換なしで直接比較することはできません 値ならば、異なる列の

比較は 索引の使用を妨げることがあります。数字の 列が文字列と比較されるとします。 数字列の の1などの特定の値の場合、文字列 の値と、 '1'、 '1'、 '00001' 。これは、文字列のインデックスを のインデックスの使用を排除します。

推測2:あなたのblogidは索引付けされていません。

推測3:レポート表はmyisamです。この場合、データを変更すると、MySQLはテーブル全体でreportsテーブルレベルロックを使用します。ブログを閲覧するたびに新しいレコードが追加されます。これらの頻繁な更新により、テーブルレベルのロックが発生し、選択クエリが遅くなる可能性があります。

これ以外のクエリは正常です。

乾杯!

+0

ありがとう私はそれとそのint(11)をチェック! – gus

+0

次に、インデックス作成を調べるために、テーブル作成ステートメントを投稿します。私はこのクエリが何の理由もなく長時間ハングしているとは信じられない - (4秒/ 170K行)。 –

+0

もう一度チェックしても問題は解決されませんでしたが、クエリキャッシュがオンになっています。 – gus

関連する問題