Optymalizacja zapytania, Mam sporo informacji ale nie potrafię sobie z tym poradzić Opcje

[TomASS]

Cześć, mam takie oto zapytanie:

[SQL] pobierz, plaintext 
SELECT 
  DISTINCT T.NumerRef 
FROM 
  m_transporty_miejsca AS TM LEFT JOIN 
  m_transporty AS T ON (T.ID=TM.ID_transport) 
WHERE 
  1 AND 
  (AnulowanyFE2='0' OR DateRealizacji>='2011-06-29') AND 
  1 AND 
  T.Odleglosc>='0' AND 
  T.Odleglosc<='99' AND 
  T.ImportFE='1' AND 
  ( T.ID_przewoznik='72' OR (STATUS='przedstawiony' AND 1) OR (Gielda='1' AND STATUS='gielda' AND 1) ) AND 
  ( Miejsce='akt' OR (STATUS='zaksięgowane w SAP' AND DataDostarczenia IS NULL) ) 
ORDER BY T.ID 
[SQL] pobierz, plaintext 

Tabela m_transporty_miejsca 200 000 rekordów
Tabela m_transporty 100 000 rekordów
raczej małe ilości.

Zapytanie wykonuje się około 0,8s (średnia z 20pomiarów).
Jeśli usunę ostatni warunek w klauzuli WHERE:

[SQL] pobierz, plaintext 
 ( Miejsce='akt' OR (STATUS='zaksięgowane w SAP' AND DataDostarczenia IS NULL) ) 
[SQL] pobierz, plaintext 

a szczególnie

[SQL] pobierz, plaintext 
OR (STATUS='zaksięgowane w SAP' AND DataDostarczenia IS NULL) 
[SQL] pobierz, plaintext 

wówczas czas zapytania spada do 0,03 (średnia z 20pomiarów)

Indexy jakie min. mam pozakładane na tabelę m_transporty to:
ImportFE1: (ImportFE)
ImportFE2: (ImportFE+Miejsce)
ImportFE3: (ImportFE+Status+DataDostarczenia)

EXPLAIN tego zapytania wskazuje, że użyty jest indeks "ImportFE1"

Proszę o pomoc w optymalizacji.

[nospor]

STATUS powinno być ENUM a nie smallint. Wówczas nie trzeba będzie zmieniać zapytań, które zapewne się przewalają przez całą aplikację.

Gielda - ENUM 0,1,2,3

Trochę dziwne używać ENUM dla wartosci numerycznych (IMG:style_emoticons/default/wink.gif)

[uupah5]

cytat z mauala mysql:
we strongly recommend that you do not use numbers as enumeration values

poza tym, wrzuć w goole "why enum is evil" albo poszukaj na forum, bo chyba już kiedyś zapodawałem linka z art. na ten temat

a co do braku efektu po zmianach - status jest zaindeksowane?

ps piszesz, że chcesz uniknąć przeróbek. obym był złym prorokiem, ale moim zdaniem źle zaprojektowana baza danych da Ci się we znaki jeszcze nie raz