dla zapytania:
WHERE NOW() >= date_from
AND NOW() <= date_to
indeks związek (date_from, date_to)
jest bezużyteczny.
Utwórz oba indeksy: (date_from)
i (date_to)
i pozwól, aby optymalizator SQL decydował za każdym razem, którego użyć. W zależności od wartości i selektywności optymalizator może wybrać jeden lub drugi indeks. Ani żadnego z nich. Nie ma łatwego sposobu na stworzenie indeksu, który uwzględni oba warunki.
(Do zoptymalizowania takiego warunku można użyć indeksu przestrzennego, jeśli można przetłumaczyć daty na szerokość i długość geograficzną).
Aktualizacja
Mój błąd. Indeks na (date_from, date_to, object_id)
może i jest rzeczywiście używany w niektórych sytuacjach dla tego zapytania. Jeśli selektywność parametru NOW() <= date_from
jest wystarczająco wysoka, optymalizator zdecyduje się użyć tego indeksu, zamiast wykonywać pełne skanowanie na stole lub używając innego indeksu. Dzieje się tak dlatego, że jest to indeks obejmujący, co oznacza, że nie ma potrzeby pobierania danych z tabeli, wymagane jest tylko odczytanie z danych indeksu.
Drobna uwaga (niezwiązana z wydajnością, tylko poprawność zapytania). Twój stan jest równoznaczne z:
WHERE CURRENT_DATE() >= date_from
AND (CURRENT_DATE() + INTERVAL 1 DAY <= date_to
OR (CURRENT_DATE() = NOW()
AND CURRENT_DATE() = date_to
)
)
Czy na pewno chcesz, czy chcesz to:
WHERE CURRENT_DATE() >= date_from
AND CURRENT_DATE() <= date_to
Funkcja NOW()
zwraca DATETIME
, natomiast CURRENT_DATE()
zwraca DATE
, bez części czasu.
Czuję date_from lepiej jest utworzyć indeks zamiast połączonego –
[prawdopodobnie] czujesz się źle. Powiedzmy, że dla jakiegoś obiektu jest 10 wierszy. 8 ma datę zakończenia w przeszłości, 1 to "current", a 1 "future". Ile z nich zostanie odfiltrowanych przez "NOW()> date_from" (odpowiedź: tylko jedna) i ilu zostanie odfiltrowanych przez "NOW()