Jakie opcje konfiguracji MySQL zapewniają największą poprawę prędkości?

Jakie opcje konfiguracji MySQL zapewniają największą poprawę prędkości?

Zastanawiam się nad faktycznymi ulepszeniami plików konfiguracyjnych, typami tabel, konfiguracjami sprzętowymi, replikacją itp. Wszystko inne niż struktura zapytań i struktura tabel (są one łatwe do znalezienia na stronie internetowej i przepełnieniu stosu). Czy takie rzeczy jak ustawienia pamięci podręcznej zapytań dały Ci największą prędkość? Co powiesz na dyski; czy lepiej mieć go na zewnętrznej macierzy RAID czy wewnętrznej? Czy replikacja zapewnia lepszą wydajność, szczególnie w przypadku odczytu dużych zapytań?

Jakie inne ustawienia / zmiany wprowadziłeś w celu poprawy wydajności MySQL?

Uwaga: zdaję sobie sprawę, że są one bardzo zależne od użycia (tj. Mała strona internetowa lub hurtownia danych), ale ponieważ myślę, że większość z nas prawdopodobnie pracuje na różnych stronach / systemach, dobrze jest znać różne techniki, które można zastosować do różnych sytuacje. Myślę też, że niektóre techniki można przenosić między sytuacjami.

Oto moje rekomendacje (twój przebieg może się różnić)

• Użyj sprzętowej macierzy RAID. Jest to sprzeczne z moimi zaleceniami dotyczącymi używania oprogramowania RAID w innych postach, jednak jest to szczególna sytuacja, w której potrzebujesz sprzętowej karty RAID. W szczególności chcesz, aby NVRAM z podtrzymaniem bateryjnym na karcie RAID skrócił czas przenoszenia pliku dziennika na dysk.
• Używaj WYŁĄCZNIE woluminów RAID 1 lub RAID 10. Koszt zapisu RAID 5 lub 6 jest zbyt wysoki, aby tolerować mieszane obciążenie odczytu / zapisu.
• Użyj osobnych jednostek LUN dla woluminów danych, dziennika i tmp. Wszystkie powinny być niezależne od systemu operacyjnego i woluminów wymiany.
• Użyj InnoDB .
• Użyj innodb_file_per_table
• Użyj 64-bitowego systemu operacyjnego
• Ustaw pulę buforów InnoDB na ~ 80% dostępnej pamięci RAM
• Ustaw swoje pliki dziennika na 1/4 wielkości puli buforów, od 2 do 4 plików dziennika. Większe pliki dziennika oznaczają wolniejsze czasy zamykania i odzyskiwania, ale pozwalają szybciej przywracać duże zrzuty bazy danych.
• log_slow_queries, log-queries-not-using-indexes, set-variable = long_query_time = 1, sprawdzaj każde zapytanie w tym dzienniku, refaktoryzuj swój schemat, aby w miarę możliwości unikać skanowania tabel i tabel tmp.

Po raz kolejny Dave Cheney naprawdę znokautował go tutaj z parku. Naprawdę nie mogę dodać nic do jego odpowiedzi na twoje pytanie. Chciałbym jednak zwrócić uwagę na to, o co nie pytałeś. Jak Jeremy Zawodny i Peter Zaitsev nauczyli mnie lata temu, twój ROI za czas poświęcony na śledzenie i optymalizację złych zapytań sprawi, że osiągniesz ROI za czas poświęcony 10-krotnym zmianom konfiguracji. Jasne, nie chcesz mieć złej konfiguracji, niewłaściwej konfiguracji RAID lub niewystarczającej pamięci RAM. Jednak wśród doskonałych, a nawet marginalnych, złe zapytania MySQL DBA (zwykle od programistów / frameworków, a nie DBA) są stanem chronicznym , w którym zła konfiguracja jest znośna .

(Kopałem dla tych przymiotników przez jakiś czas i nadal nie jestem zadowolony z tych, które wybrałem).

Chciałbym jeszcze raz podkreślić, że jeśli programiści używają ORM, takich jak te powszechnie stosowane w frameworkach takich jak Ruby on Rails i Django, NAPRAWDĘ MUSISZ monitorować zapytania trafiające na twoją bazę danych. Kiedy programiści przestają myśleć o SQL i pozwalają abstrakcji DB oderwać się od rzeczywistości, to naprawdę paskudne wkrada się. Uwielbiam dwa frameworki, o których właśnie wspomniałem. (Nie głosuj za mną z powodu złych ust.) To sprawia, że ​​Query Sleuthing jest bardzo ważne. (Czytaj: Bezpieczeństwo pracy)

Kilka innych rzeczy (o których nie wspomniano w odpowiedzi Dave'a Cheneya)

• Spróbuj ustawić innodb_flush_method na O_DIRECT, aby uniknąć podwójnego buforowania danych. Unikaj tego, jeśli karta RAID nie ma pamięci podręcznej zapisu opartej na akumulatorze lub dane znajdują się w sieci SAN.

• Graj także za pomocą innodb_thread_concurrency. Uważam, że domyślnie jest to 8, ale warto to zmienić, aby zobaczyć, czy poprawi to wydajność

• Upewnij się, że pamięć podręczna zapytań jest włączona i sprawdź statystyki, aby zobaczyć, jaki jest współczynnik trafień. Jeśli to dobrze, spróbuj go zwiększyć, aby sprawdzić, czy poprawi to współczynnik trafień.

• W zależności od uruchomionych aplikacji możesz zmienić domyślny poziom izolacji. Wartość domyślna to REPEATABLE_READ, ale READ_COMMITTED może dać lepszą wydajność

• Jeśli twoje instrukcje to głównie AKTUALIZACJE i USUŃ, możesz spróbować uruchomić pamięć podręczną na urządzeniu podrzędnym, wykonując zapytanie SELECT, które zwraca zestaw wyników, który ma zostać zmodyfikowany. Sprawdź narzędzie mk-slave-prefetch , które zrobi to za Ciebie

• Spójrz na inne silniki pamięci masowej oprócz MyISAM i InnoDB

Nie mogę nic powiedzieć o sprzęcie, ale możesz spróbować http://blog.mysqltuner.com . Jest to skrypt Perla, który analizuje twoje ustawienia MySQL.

Przykładowe dane wyjściowe można zobaczyć na stronie http://www.thomas-krenn.com/de/wiki/MySQL_Performance_Tuning#mysqltuner.pl

Pierwszą ogólną rzeczą, którą powinieneś zrobić, to spojrzeć na parametry pamięci. Domyślne ustawienia MySQL są bardzo konserwatywne. Bez względu na to, jakiego silnika użyjesz, prawdopodobnie będziesz musiał zwiększyć liczbę parametrów pamięci o dziesięć, a nawet sto razy.

Następną rzeczą, którą powinieneś zrobić, to spojrzeć na pamięć podręczną tabeli. Wartość domyślna to 64, co jest użyteczne tylko wtedy, gdy masz nie więcej niż około 60 tabel. Będziesz chciał podnieść to daleko.

Trzecią rzeczą, którą powinieneś zrobić, to spojrzeć na parametry wątku i połączenia. Domyślny czas oczekiwania jest długi dla większości aplikacji internetowych i może zostać skrócony do około 30 sekund. Poprawi to również wykorzystanie pamięci, ponieważ MySQL szybciej zbierze połączenia, pozostawiając znacznie mniej leżących w stanie „uśpienia”.