Maksymalne wykorzystanie pamięci przez MySQL w dużej mierze zależy od sprzętu, Twoich ustawień i samą bazę danych.
Sprzęt
Sprzęt jest oczywistą częścią. Im więcej pamięci RAM, tym weselej, szybsze dyski ftw . Nie wierz jednak w te comiesięczne lub cotygodniowe wiadomości. MySQL nie skaluje się liniowo — nawet na sprzęcie Oracle. To trochę trudniejsze.
Najważniejsze jest to, że nie ma ogólnej zasady dotyczącej tego, co jest zalecane dla Twojego Konfiguracja MySQL. Wszystko zależy od bieżącego użytkowania lub prognoz.
Ustawienia i baza danych
MySQL oferuje niezliczone zmienne i przełączniki optymalizujące jego zachowanie. Jeśli napotkasz problemy, naprawdę musisz usiąść i przeczytać (f'ing) podręcznik.
Jeśli chodzi o bazę danych — kilka ważnych ograniczeń:
- silnik tabel (
InnoDB,MyISAM, ...) - rozmiar
- indeksy
- wykorzystanie
Większość porad MySQL dotyczących przepełnienia stosu zawiera informacje o 5-8 tak zwanych ważnych ustawieniach. Po pierwsze, nie wszystkie z nich mają znaczenie – m.in. przydzielanie dużej ilości zasobów do InnoDB i nieużywanie InnoDB nie ma większego sensu, ponieważ te zasoby są marnowane.
Lub - wiele osób sugeruje zwiększenie max_connection zmienna -- cóż, niewiele wiedzą, że oznacza to również, że MySQL przydzieli więcej zasobów, aby obsłużyć te max_connections - jeśli kiedykolwiek będzie to potrzebne. Bardziej oczywistym rozwiązaniem może być zamknięcie połączenia z bazą danych w twoim DBAL lub obniżenie wait_timeout aby uwolnić te wątki.
Jeśli złapiesz mój dryf – jest naprawdę dużo, dużo do przeczytania i nauczenia się.
Silniki
Silniki tabel to dość ważna decyzja, wiele osób wcześnie o nich zapomina, a potem nagle zaczyna walczyć z MyISAM wielkości 30 GB tabela, która blokuje i blokuje całą ich aplikację.
Nie chcę powiedzieć, że MyISAM jest do bani , ale InnoDB można dostosować, aby odpowiadał prawie lub prawie tak szybko, jak MyISAM i oferuje coś takiego jak blokowanie wierszy w UPDATE podczas gdy MyISAM blokuje całą tabelę, gdy jest do niej zapisywana.
Jeśli masz swobodę uruchamiania MySQL we własnej infrastrukturze, możesz również zapoznać się z serwer percona
ponieważ wśród wielu wkładów firm takich jak Facebook i Google (które wiedzą szybko), zawiera również własny zamiennik dla InnoDB firmy Percona , o nazwie XtraDB .
Zobacz mój gist dla konfiguracji percona-server (i -client) (na Ubuntu):http://gist.github .com/637669
Rozmiar
Rozmiar bazy danych jest bardzo, bardzo ważny – wierz lub nie, większość ludzi w Intarwebs nigdy nie miała do czynienia z dużą i intensywną konfiguracją MySQL, ale tak naprawdę istnieją. Niektórzy będą trollować i mówić coś w stylu „Użyj PostgreSQL!!!111”, ale na razie ich zignorujmy.
Najważniejsze jest to:sądząc po rozmiarze, należy podjąć decyzję o sprzęcie. Nie da się tak naprawdę sprawić, by baza danych o pojemności 80 GB działała szybko na 1 GB pamięci RAM.
Indeksy
Nie jest:im więcej, tym weselej. Należy ustawić tylko potrzebne indeksy i sprawdzić użycie za pomocą EXPLAIN . Dodaj do tego EXPLAIN MySQL jest naprawdę ograniczony, ale to dopiero początek.
Sugerowane konfiguracje
Informacje o my-large.cnf i my-medium.cnf akta -- nawet nie wiem, dla kogo zostały napisane. Rzuć własne.
Podkład tuningowy
Świetnym początkiem jest podkład strojenia
. Jest to skrypt bash (wskazówka:potrzebujesz linuxa), który pobiera wyjście SHOW VARIABLES i SHOW STATUS i zamienia go w miejmy nadzieję użyteczną rekomendację. Jeśli Twój serwer działał przez jakiś czas, rekomendacja będzie lepsza, ponieważ będą dostępne dane, na których można je oprzeć.
Podkład tuningowy nie jest jednak magicznym sosem. Powinieneś przeczytać wszystkie zmienne, które sugeruje się zmienić.
Czytanie
Naprawdę lubię polecić mysqlperformanceblog . To świetne źródło wszelkiego rodzaju porad dotyczących MySQL. I nie chodzi tylko o MySQL, oni również dużo wiedzą o odpowiednim sprzęcie lub polecają konfiguracje dla AWS itp. Ci goście mają wieloletnie doświadczenie.
Innym świetnym źródłem informacji jest planet-mysql , oczywiście.
