SUMを使用した場合のMySQLクエリパフォーマンスの向上

Question

ステータス用のENUM形式の列を含むユーザー生成コンテンツの表があります。 （保留、承認、承認、自動、また​​は拒否）の状態で、最近のコンテンツの量に目途中に保つために、私は次のクエリを使用します。

mysql> SELECT DATE(dt_submitted) AS date, 
       COUNT(*) AS count, 
       SUM(IF(status='Approved', 1, 0)) as approved, 
       SUM(IF(status='Approved-auto', 1, 0)) as approved_auto, 
       SUM(IF(status='Rejected', 1, 0)) as rejected, 
       SUM(IF(status='Pending', 1, 0)) as pending 
     FROM post 
     WHERE dt_submitted > DATE_SUB(CURDATE(), INTERVAL 30 DAY) 
     GROUP BY date; 
+------------+-------+----------+---------------+----------+---------+ 
| date  | count | approved | approved_auto | rejected | pending | 
+------------+-------+----------+---------------+----------+---------+ 
| 2011-11-22 | 131 |  124 |    0 |  7 |  0 | 
| 2011-11-23 | 116 |  114 |    0 |  2 |  0 | 
... 
| 2011-12-21 | 690 |  674 |    5 |  11 |  0 | 
| 2011-12-22 | 80 |  75 |    0 |  4 |  38 | 
+------------+-------+----------+---------------+----------+---------+ 
31 rows in set (0.60 sec) 

をこれはほぼ完璧ですが、私は好き嫌いだとしたいです私はそれをより速くすることができるかどうかを知るために。 （0.6秒は、このサーバー上に遅く、テーブルはキャッシュ結果に静的な日付を渡して心配する必要はあまりにも頻繁に変更されます。）

私は、クエリをEXPLAINした場合、それは（statusがインデックス化された）任意のインデックスを使用していません。 （それは合算のために作成された一時テーブルを参照しているため、このですか？）

explain SELECT DATE(dt_submitted) AS date, COUNT(*) AS count, SUM(IF(status='Approved', 1, 0)) as approved, SUM(IF(status='Approved-auto', 1, 0)) as approved_auto, SUM(IF(status='Rejected', 1, 0)) as rejected, SUM(IF(status='Pending', 1, 0)) as pending FROM post WHERE dt_submitted > DATE_SUB(CURDATE(), INTERVAL 30 DAY) GROUP BY date; 
+----+-------------+-------+------+---------------+------+---------+------+--------+----------------------------------------------+ 
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra          | 
+----+-------------+-------+------+---------------+------+---------+------+--------+----------------------------------------------+ 
| 1 | SIMPLE  | post | ALL | NULL   | NULL | NULL | NULL | 529902 | Using where; Using temporary; Using filesort | 
+----+-------------+-------+------+---------------+------+---------+------+--------+----------------------------------------------+ 
1 row in set (0.00 sec) 

だから私はテーブルを最適化したり、これはより高速にするために問合せをリライトするために何かできることはありますか？または、このクエリは、利用可能なシステムリソースの速度によって単純に制限されていますか？

編集：dt_submittedは索引付けされませんでした。

Answer 1

適切な列が索引付けされていることを再度確認します。

（編集で述べたように、私は私のインデックスを再確認することができなかった。私は適切な列をインデックス化すると、問題が解決した。）