Максималното използване на паметта на MySQL зависи много от хардуера, вашите настройки и самата база данни.
Хардуер
Хардуерът е очевидната част. Колкото повече RAM, толкова по-добре, по-бързи дискове ftw . Не вярвайте на тези месечни или седмични новинарски писма. MySQL не мащабира линейно - дори на хардуера на Oracle. Малко по-сложно е от това.
Изводът е:няма общо правило за това какво се препоръчва завашатата Настройка на MySQL. Всичко зависи от текущото използване или прогнозите.
Настройки и база данни
MySQL предлага безброй променливи и превключватели за оптимизиране на поведението му. Ако срещнете проблеми, наистина трябва да седнете и да прочетете (ф'инг) ръководството.
Що се отнася до базата данни - няколко важни ограничения:
- машина за таблици (
InnoDB,MyISAM, ...) - размер
- индекси
- използване
Повечето MySQL съвети за stackoverflow ще ви разкажат за 5-8 така наречените важни настройки. Първо, не всички от тях имат значение - напр. разпределянето на много ресурси за InnoDB и неизползването на InnoDB няма голям смисъл, защото тези ресурси се прахосват.
Или - много хора предлагат да увеличите max_connection променлива - добре, те малко знаят, че това също предполага, че MySQL ще задели повече ресурси за обслужване на тези max_connections -- ако има нужда. По-очевидното решение може да бъде да затворите връзката към базата данни във вашия DBAL или да намалите wait_timeout за да освободите тези нишки.
Ако схванете моето отклонение - наистина има много, много за четене и научаване.
Двигатели
Таблиците са доста важно решение, много хора забравят за тях рано и след това изведнъж се борят с 30 GB MyISAM таблица, която се заключва и блокира цялото им приложение.
Не искам да кажа MyISAM е гадно , но InnoDB може да бъде настроен, за да отговаря почти или почти толкова бързо, колкото MyISAM и предлага такова нещо като заключване на ред при UPDATE докато MyISAM заключва цялата таблица, когато е записана.
Ако сте свободни да стартирате MySQL в собствената си инфраструктура, може да искате да разгледате percona сървър
защото сред включването на много приноси от компании като Facebook и Google (те знаят бързо), включва също и собствената замяна на Percona за InnoDB , наречен XtraDB .
Вижте моята същност за настройка на percona-server (и -client) (в Ubuntu):http://gist.github .com/637669
Размер
Размерът на базата данни е много, много важен - вярвате или не, повечето хора в Intarwebs никога не са се занимавали с голяма и интензивна настройка на MySQL, но те наистина съществуват. Някои хора ще тролират и ще кажат нещо като „Използвайте PostgreSQL!!!111“, но нека ги игнорираме засега.
Изводът е:съдейки от размера, трябва да се вземе решение за хардуера. Не можете наистина да накарате база данни от 80 GB да работи бързо на 1 GB RAM.
Индекси
Не е:колкото повече, толкова по-весело. Трябва да се зададат само необходими индекси и използването трябва да се провери с EXPLAIN . Добавете към това EXPLAIN на MySQL е наистина ограничено, но е начало.
Предложени конфигурации
Относно тези my-large.cnf и my-medium.cnf файлове -- дори не знам за кого са написани. Навийте своя собствен.
Тунинг грунд
Чудесно начало е настройката
. Това е bash скрипт (подсказка:ще ви трябва linux), който взема изхода на SHOW VARIABLES и SHOW STATUS и го обгръща в, надявам се, полезна препоръка. Ако сървърът ви е работил известно време, препоръката ще бъде по-добра, тъй като ще има данни, на които да ги базирате.
Тунинг грундът обаче не е вълшебен сос. Все пак трябва да прочетете всички променливи, които предлага да промените.
Четене
Наистина искам да препоръчам mysqlperformanceblog . Това е чудесен ресурс за всякакви съвети, свързани с MySQL. И не е само MySQL, те също знаят много за правилния хардуер или препоръчват настройки за AWS и т.н. Тези момчета имат години и години опит.
Друг страхотен ресурс е planet-mysql , разбира се.
