必要以上に実行速度が遅いクエリがあります。問題を単純な select ステートメントに絞り込みました (一部のフィールドはプライバシーのために名前が変更されています)。
SELECT SQL_NO_CACHE SQL_CALC_FOUND_ROWS id, date_started, date_complete, status
FROM table_a
ORDER BY date DESC
LIMIT 0, 100
を使用するSQL_CALC_FOUND_ROWSと、クエリは約 0.70 秒で完了しますが、SQL_CALC_FOUND_ROWSを削除すると、クエリは約 0.0005 秒で完了します (どちらの場合もSQL_NO_CACHEクエリで使用されます)。
table_aフィールドにインデックスがありdateます。
どうやら SQL_CALC_FOUND_ROWSはインデックスの使用を防ぐことができます:
したがって、この単純なテストから明らかな結論は、クエリの WHERE/ORDER 句に適切なインデックスがある場合、SQL_CALC_FOUND_ROWS を使用して 1 つのクエリを使用するよりも、2 つの個別のクエリを使用する方がはるかに高速であることです。
私はこれを確認しました。SQL_CALC_FOUND_ROWSが含まれている場合、インデックスは使用されません。
EXPLAIN SELECT SQL_NO_CACHE SQL_CALC_FOUND_ROWS id, date_started, date_complete, status FROM table_a ORDER BY date DESC limit 0, 100;
+----+-------------+-------------+------+---------------+------+---------+------+--------+----------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------------+------+---------------+------+---------+------+--------+----------------+
| 1 | SIMPLE | table_a | ALL | NULL | NULL | NULL | NULL | 132208 | Using filesort |
+----+-------------+-------------+------+---------------+------+---------+------+--------+----------------+
ただし、SQL_CALC_FOUND_ROWSが使用されていない場合は、日付フィールドのインデックスが使用されます。
EXPLAIN SELECT SQL_NO_CACHE id, date_started, date_complete, status FROM table_a ORDER BY date DESC limit 0, 100;
+----+-------------+-------------+-------+---------------+------+---------+------+--------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------------+-------+---------------+------+---------+------+--------+-------+
| 1 | SIMPLE | table_a | index | NULL | date | 13 | NULL | 132208 | |
+----+-------------+-------------+-------+---------------+------+---------+------+--------+-------+
クエリから削除せずにクエリを高速化する方法はありSQL_CALC_FOUND_ROWSますか?
MySQL バージョン 5.0.51a-3ubuntu5.1-log を使用しています。