MySQL
Porady dotyczące wydajności MySQL

Wybierz opcję Optymalizacja instrukcji

Poniżej znajduje się kilka wskazówek, o których należy pamiętać podczas pisania wybranego zapytania w MySQL, które może nam pomóc i skrócić czas zapytania: -

1. Ilekroć używamy gdzie w dużej tabeli, powinniśmy upewnić się, że kolumna, w której klauzula jest indeksowana, czy nie. Np .: - Wybierz * z pracownika, gdzie identyfikator_użytkownika> 2000. identyfikator_użytkownika, jeśli jest indeksowany, przyspieszy ocenę atlotu zapytania. Indeksy są również bardzo ważne podczas łączenia i kluczy obcych.

2. Jeśli potrzebujesz mniejszej sekcji treści zamiast pobierania całych danych z tabeli, spróbuj użyć limitu. Zamiast pisać np.: - Wybierz * od pracownika. Jeśli potrzebujesz tylko pierwszych 20 pracowników z lakhs, po prostu użyj limitu Np .: - Wybierz * z pracownika LIMIT 20.

3. Możesz również zoptymalizować zapytanie, podając nazwę kolumny, którą chcesz w zestawie wyników. Zamiast pisać np.: - Wybierz * od pracownika. Podaj tylko nazwę kolumny, z której potrzebujesz danych, jeśli tabela zawiera wiele kolumn i chcesz mieć dane dla kilku z nich. Np .: - Wybierz identyfikator, imię i nazwisko pracownika.

4. Kolumna indeksu, jeśli używasz do sprawdzenia wartości NULL w klauzuli where. Jeśli masz jakąś instrukcję jako SELECT * FROM tbl_name WHERE key_col IS NULL; następnie jeśli indeks_klucza jest indeksowany, zapytanie zostanie ocenione szybciej.

Optymalizacja układu pamięci dla tabel InnoDB

1. W InnoDB posiadanie długiego KLUCZA PODSTAWOWEGO (pojedyncza kolumna o długiej wartości lub kilka kolumn tworzących długą wartość złożoną) marnuje dużo miejsca na dysku. Wartość klucza podstawowego dla wiersza jest powielana we wszystkich rekordach indeksu dodatkowego wskazujących na ten sam wiersz. Utwórz kolumnę AUTO_INCREMENT jako klucz podstawowy, jeśli klucz podstawowy jest długi.
2. Użyj typu danych VARCHAR zamiast CHAR, aby przechowywać ciągi o zmiennej długości lub kolumny z wieloma wartościami NULL. Kolumna CHAR (N) zawsze przyjmuje N znaków do przechowywania danych, nawet jeśli łańcuch jest krótszy lub jego wartość to NULL. Mniejsze tabele lepiej pasują do puli buforów i zmniejszają liczbę operacji we / wy dysku.

Podczas korzystania z formatu wiersza COMPACT (domyślny format InnoDB) i zestawów znaków o zmiennej długości, takich jak utf8 lub sjis, kolumny CHAR (N) zajmują zmienną ilość miejsca, ale nadal co najmniej N bajtów.

3. W przypadku tabel, które są duże lub zawierają wiele powtarzających się tekstów lub danych liczbowych, rozważ użycie formatu wiersza SPRĘŻONEGO. Do przeniesienia danych do puli buforów lub wykonania pełnego skanowania tabeli wymagana jest mniejsza ilość operacji we / wy dysku. Przed podjęciem stałej decyzji zmierzyć stopień kompresji, jaki można osiągnąć, stosując format wierszy COMPRESSED w porównaniu z formatem COMPACT. Uwaga: Testy porównawcze rzadko wykazują lepszą kompresję niż 2: 1, a dla parametru COMPRESSED występuje duże obciążenie.
4. Gdy Twoje dane osiągną stabilny rozmiar lub rosnąca tabela zwiększy się o kilkadziesiąt lub kilkaset megabajtów, rozważ użycie instrukcji OPTIMIZE TABLE w celu reorganizacji tabeli i zagęszczenia zmarnowanej przestrzeni. Zreorganizowane tabele wymagają mniejszej liczby operacji we / wy dysku, aby wykonać pełne skanowanie tabeli. Jest to prosta technika, która może poprawić wydajność, gdy inne techniki, takie jak poprawa wykorzystania indeksu lub strojenie kodu aplikacji, nie są praktyczne. Uwaga : Niezależnie od wielkości stołu OPTYMALIZACJA TABELI powinna być wykonywana rzadko. Jest tak, ponieważ jest kosztowne i rzadko poprawia stół na tyle, aby był tego wart. InnoDB jest dość dobry w utrzymywaniu drzew B + w wolnej przestrzeni od dużej ilości zmarnowanego miejsca.

OPTYMALIZUJ TABELĘ kopiuje część danych tabeli i odbudowuje indeksy. Korzyści wynikają z lepszego pakowania danych w indeksach i zmniejszonej fragmentacji w obszarach tabel i na dysku. Korzyści różnią się w zależności od danych w każdej tabeli. Może się okazać, że dla niektórych istnieją znaczne zyski, a dla innych nie, lub że zyski zmniejszają się z czasem, aż do następnej optymalizacji tabeli. Ta operacja może być powolna, jeśli tabela jest duża lub jeśli przebudowywane indeksy nie pasują do puli buforów. Pierwsze uruchomienie po dodaniu dużej ilości danych do tabeli jest często znacznie wolniejsze niż późniejsze.

Budowanie indeksu złożonego

W wielu sytuacjach indeks złożony działa lepiej niż indeks z pojedynczą kolumną. Aby zbudować optymalny indeks kompozytowy, wypełnij go kolumnami w tej kolejności.

• = kolumny z klauzuli WHERE pierwsze. (np. INDEX(a,b,...) dla WHERE a=12 AND b='xyz' ... )
• Kolumna (kolumny) IN ; optymalizator może przeskoczyć przez indeks.
• Jeden „zakres” (np. x BETWEEN 3 AND 9 , name LIKE 'J%' ) Nie wykorzysta niczego poza kolumną pierwszego zakresu.
• Wszystkie kolumny w GROUP BY , w kolejności
• Wszystkie kolumny w ORDER BY , w porządku. Działa tylko, jeśli wszystkie są ASC lub wszystkie są DESC lub używasz wersji 8.0.

Uwagi i wyjątki:

• Nie powielaj żadnych kolumn.
• Pomiń wszystkie przypadki, które nie mają zastosowania.
• Jeśli nie użyjesz wszystkich kolumn WHERE , nie musisz przechodzić do GROUP BY itp.
• Są przypadki, w których warto zaindeksować tylko kolumny ORDER BY , ignorując WHERE .
• Nie „ukrywaj” kolumny w funkcji (np. DATE(x) = ... nie można użyć x w indeksie).
• Indeksowanie „prefiksów” (np. text_col(99) ) jest mało prawdopodobne; może boleć.

Więcej informacji i wskazówek .