Optymalna konfiguracja MySQL (my.cnf)

Question

Poniżej znajduje się mój domyślny plik konfiguracyjny MySQL (my.cnf) dla czystej konfiguracji UTF-8 z InnoDB jako domyślnym silnikiem pamięci masowej.

[server] 
bind-address=127.0.0.1 
innodb_file_per_table 
default-character-set=utf8 
default-storage-engine=innodb 

Instalator wykonuje następujące operacje:

1. Wiąże się localhost: 3306 (loopback) zamiast domyślnego *: 3306 (wszystkie interfejsy). Zrobione, aby zwiększyć bezpieczeństwo.
2. Ustawia jeden obszar tabel na tabelę. Zrobione, aby zwiększyć łatwość konserwacji.
3. Ustawia domyślny zestaw znaków na UTF-8. Zrobione, aby domyślnie ułatwić internacjonalizację.
4. Ustawia domyślny mechanizm zapisu na InnoDB. Zrobione, aby domyślnie włączyć blokowanie na poziomie wiersza.

Załóżmy, że możesz ulepszyć konfigurację, dodając maksymalnie trzy (3) parametry konfiguracyjne. Co byś dodał i dlaczego?

Udoskonalenie w tym kontekście oznacza poprawę wydajności, poprawę niezawodności lub łatwość obsługi/łatwość konserwacji. Można założyć, że komputer z instancją MySQL będzie miał 1000 MB pamięci RAM.

Answer 1

Aby buforować więcej danych:

innodb_buffer_pool_size = 512M 

Jeśli piszesz dużo danych:

innodb_log_file_size = 128M 

, aby uniknąć zbyt dużo przełączanie dziennika.

Nie ma żadnej trzeciej, którą bym dodał w każdym przypadku, wszystkie inne zależą.

Answer 2

Zwiększ wielkość puli bufora InnoDB, tak duży jak można praktycznie zrobić to:

innodb_buffer_pool_size=768M 

Będziesz także chcą jakąś kluczową przestrzeń buforową dla tabel temp:

key_buffer_size=32M 

Inne zależałaby na temat tego, co robisz z bazą danych, ale table_cache lub query_cache_size to kilka innych potencjałów.

Answer 3

Przeznaczenie większej ilości pamięci niż domyślna wartość 8M na InnoDB (przy użyciu innodb_buffer_pool_size) jest niewątpliwie ulepszeniem. Jeśli chodzi o wartość, na dedykowanym serwerze bazy danych możesz ustawić go na 80% pamięci RAM, a im wyższa ustawisz tę wartość, tym mniej będzie interakcji z dyskiem twardym. Wystarczy dać moje dwa centy, chciałbym wspomnieć, że można mieć jakiś wzrost wydajności szczypanie wartość innodb_flush_log_at_trx_commit jednak poświęcania zgodności ACID ... Według MySQL manual:

Jeżeli wartość innodb_flush_log_at_trx_commit to 0, bufor dziennika jest zapisywany do pliku dziennika raz na sekundę, a operacja opróżniania do operacji na dysku jest wykonywana w pliku dziennika , ale nic nie jest wykonywane przy zatwierdzaniu transakcji .

Możesz utracić dane, które nie zostały poprawnie zapisane w bazie danych z powodu awarii lub jakiejkolwiek awarii. Ponownie według instrukcji MySQL:

Jednak odzyskiwania katastrofy InnoDB jest nie ma wpływu, a tym samym odtwarzanie po awarii działa niezależnie od wartości.

Więc proponuję:

innodb_flush_log_at_trx_commit = 0 

Wreszcie, jeśli masz dużą szybkość połączenia (czyli jeśli trzeba skonfigurować MySQL do obsługi aplikacji internetowej, która ma dostęp do bazy danych), wówczas należy rozważyć zwiększenie maksymalna liczba połączeń z czymś w rodzaju 500. Ale ponieważ jest to coś mniej lub bardziej banalnego i dobrze znanego, dlatego chciałbym podkreślić, że ważne jest, aby mieć pewność, że ważne jest, aby back_log zapewnić łączność.

Mam nadzieję, że te informacje pomogą w zoptymalizowaniu serwera bazy danych.