![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 243 Pomógł: 0 Dołączył: 30.11.2003 Ostrzeżenie: (0%) ![]() ![]() |
Czy ktoś może mi powiedzieć, jakie są zasady tworzenia przez MySQL tabel
tymczasowych przy wykonywaniu zapytań SELECT? Spotykam się niejednokrotnie, że analiza zapytania (EXPLAIN SELECT ...) ujawnia w kolumnie EXTRA wartość "USING TEMPORARY". Podejrzewam, że ma to negatywny wpływ na wydajność. Zapytanie mam takie:
a więc zupełnie proste... Ten IF jest nie do uniknięcia - zapytanie ma zwracać sumę i ilość transakcji różnych typów, w powyższym przykładzie pozostawiłem jedynie jedną kolumnę. Tak czy owak nawet powyższe zapytanie generuje "USING TEMPORARY" dla tabeli Transakcje. Indeksy są na wszystkich złączeniach, a mimo to MySQL nie korzysta z indeksu "KtoWpisal". Dlaczego? MySQL 4.0.18 Pozdrawiam, Krzysiek |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Zarząd Postów: 2 277 Pomógł: 6 Dołączył: 27.12.2002 Skąd: Wołów/Wrocław ![]() |
Przy grupowaniu - zawsze wykorzystywane jest temporary, jednak zazwyzaj nie odbija się to w zbyt drastyczny sposób na wydajności.
Natomiast co do index - jeśli możesz - udostępnij strukturę interesującego nas fragmentu bazy z przykładowymi danymi (najlepiej podając plik do pobania, a nie wklejając ją tu) |
|
|
![]()
Post
#3
|
|
Grupa: Zarejestrowani Postów: 243 Pomógł: 0 Dołączył: 30.11.2003 Ostrzeżenie: (0%) ![]() ![]() |
Oczywiście, ale niestety nie dysponuję serwerem dostępnym dla juzerów spoza firmy. Strukturę bazy w zakresie, który może być istotny, wklejam więc poniżej:
Będę wdzięczny za pomoc w rozwiązaniu problemu, "pałuję" się już z nim dłuższy czas i nie mam pomysłu co dalej. Dziękuję i pozdrawiam, Krzysiek |
|
|
![]()
Post
#4
|
|
Grupa: Zarząd Postów: 2 277 Pomógł: 6 Dołączył: 27.12.2002 Skąd: Wołów/Wrocław ![]() |
Moja propozycja
|
|
|
![]()
Post
#5
|
|
Grupa: Zarejestrowani Postów: 243 Pomógł: 0 Dołączył: 30.11.2003 Ostrzeżenie: (0%) ![]() ![]() |
Zastosowałem się do Twojej propozycji. Ciekawe...
Oczywiście kolejność skanowania tabel jest inna. Teraz pierwsza przeszukiwana jest tabela Oddzialy. Ale bez użycia indeksu IDOddzialu - dlaczego? Tego indeksu nie ma nawet w kolumnie POSSIBLE_KEYS... Liczba przeskanowanych rekordów jest dokładnie ta sama co poprzednio. Wygląda na to, że specjalnego przyrostu wydajności nie osiągnąłem. Ale czy ktoś potrafi wytłumaczyć, dlaczego pierwsza ze skanowanych tabel (niezależnie na którą wypadnie) zawsze przeszukiwana jest bez wykorzystania indeksu? Pozdrawiam, Krzysiek |
|
|
![]()
Post
#6
|
|
Grupa: Zarząd Postów: 2 277 Pomógł: 6 Dołączył: 27.12.2002 Skąd: Wołów/Wrocław ![]() |
1. nie ma sensu tworzyć dodatkowego indeksu IDOddzialu skoro kolumna ta jest kluczem głownym (primary) Kolumna taka jest domyślnie indeksowana.
2. Nie wiem dlaczego nie wymienia żadnego indesku w possible_keys ale wydaje mi się, że najprostrzą i najprawdziwszą odpowiedzią jest taka, że nie potrzebuje żadnego indexu. Bo sam powiedz - do trzego miałby go używać, jeśli po tej pierwszej tabeli nie ma nawet sortowania? 3. Liczba przeskanowanych rekordów. Ta mogłaby się zmienić dopiero wtedy, gdybyśmy ograniczyli ilość rekodów dołączanych. Można by to zrobić przy pomocy np. dodania warunku związanego z datą (znajdującego sie teraz w select) do JOIN transakcje i być moze zmodyfikowanie wykorzystywanego przez date indexu, Pisałeś jednak, że z pewnych względów nie możesz modyfikować tej struktury, więc nie tworzyłem takiego zapytania. |
|
|
![]() ![]() |
![]() |
Aktualny czas: 25.09.2025 - 03:13 |