に参加:d.id(PRIMARY)上のインデックス、d.added_time、dt.datum_idがあり日付範囲でのMySQLのクエリの最適化と、私は次のクエリ持っ
SELECT COUNT(*)
FROM datum d
JOIN datum_type dt
ON dt.datum_id = d.id
AND dt.type_id = '3'
WHERE d.added_time >= DATE_FORMAT(CURDATE(), '%Y-%m')
AND d.added_time < DATE_FORMAT(CURDATE() + INTERVAL 1 MONTH, '%Y-%m')
をして
をdt.type_id説明現在の計画では、次のとおりです。私たちはかなりの時間のための基準レコードを持っていたよう
+----+-------------+-------+--------+--------------------+---------+---------+-------------+--------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+--------+--------------------+---------+---------+-------------+--------+-------------+
| 1 | SIMPLE | dt | ref | type_id,datum_id | type_id | 1 | const | 602628 | |
| 1 | SIMPLE | d | eq_ref | PRIMARY,added_time | PRIMARY | 8 | dt.datum_id | 1 | Using where |
+----+-------------+-------+--------+--------------------+---------+---------+-------------+--------+-------------+
は、それが最初datum.id PRIMARYを使用して、それぞれが基準かどうかを確認するために、行に参加したスキャンタイプに加入しているように見えます。 added_timeはwです範囲内で。
私はadded_timeインデックスを使用してみましたが、計画はした説明:ほとんど限りdatum.added_timeの範囲内の異なるdatum_type.type_idのように多くのdatum_typesがあるので取り
+----+-------------+-------+-------+------------------+------------+---------+------+---------+--------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+-------+------------------+------------+---------+------+---------+--------------------------+
| 1 | SIMPLE | d | index | added_time | added_time | 4 | NULL | 6195194 | Using where; Using index |
| 1 | SIMPLE | dt | ref | type_id,datum_id | datum_id | 8 | d.id | 1 | Using where |
+----+-------------+-------+-------+------------------+------------+---------+------+---------+--------------------------+
。
これをスピードアップするインデックスの組み合わせはありますか?
(datum_id、type_id)で複合キーを試しましたか?私は実際にDATE_FORMATビットを理解していませんが、パフォーマンスにはほとんど影響しません。 – Strawberry
おっと、インデックスを試してみます。 – Arth
'datum_type'の不要な正規化? –