Що потрібно налаштувати в mySQL одразу після встановлення? Тонка настройка MySQL

Починаючи з версії 3.22, MySQL може зчитувати прийняті за замовчуванням параметри запуску для сервера та клієнтів з файлів параметрів. У Unix зчитування прийнятих за умовчанням параметрів MySQL провадиться з наступних файлів:

DATADIR є каталогом даних MySQL(зазвичай "/usr/local/mysql/data" для бінарної установки або "/usr/local/var" для установки з вихідних текстів). Зверніть увагу, що це каталог, який був заданий під час налаштування, а не вказаний за допомогою –datadir при запуску mysqld! (–datadir не впливає перегляд файлів параметрів сервером, оскільки їх перегляд відбувається до обробки аргументів командного рядка).

MySQL намагається прочитати файли параметрів у вказаному порядку. Якщо існує кілька таких файлів, то параметр, вказаний у файлі, що йде пізніше, має перевагу над таким самим параметром, зазначеним у файлі, розташованому раніше. Параметри, вказані в командному рядку, мають більш високий пріоритет щодо параметрів, зазначених у будь-якому з файлів параметрів. Деякі параметри можна задавати за допомогою змінних оточення. Параметри, вказані в командному рядку або у файлах параметрів, мають перевагу по відношенню до змінних оточення.

Наводимо список програм, що підтримують файли параметрів: mysql, mysqladmin, mysqld, mysqld_safe, mysql.server, mysqldump, mysqlimport, mysqlshow, mysqlcheck, myisamchk та myisampack.

Будь-який параметр, який може бути заданий у командному рядку під час запуску програми MySQL, може бути також заданий у файлі параметрів (без попереднього подвійного слеша). Щоб отримати список доступних параметрів, запустіть програму з параметром –help.

Параметри my.cnf MySQL 5.5 (кодування UTF8)

    Що utf8mb4? utf8mb4 - набір символів, що використовується для зберігання 4 байти MySQL, впроваджений в 2010 році починаючи з версії 5.5.3. Головна відмінність utf8mb4 від utf8 у тому, що utf8mb4 задіює більше повні можливостікодування UTF8, дозволяючи підтримувати всі мови та спеціальні символи, що не підтримують utf8 (наприклад, японська мова або смайли з ios - emoji). Однак, як можна здогадатися, якщо utf8mb4 використовує для зберігання 1 символу 4 байти, то база даних може збільшитися в розмірі, якщо порівнювати з такою самою базою даних в utf8. У наш час трохи збільшений розмір бази даних не є істотно проблемою, тому, якщо ви стоїте перед вибором використовувати utf8 або utf8mb4 набір символів - використовуйте utf8mb4.

Деякі параметри my.cnf MySQL 5.5.22 застаріли (deprecated) і були замінені іншими і видалені. Наприклад, зміна кодування за умовчанням у my.cnf у секції буде виглядати так:

#... character_set_server = utf8 # раніше default-character-set = utf8 і character_set_server = utf8 collation-server = utf8_unicode_ci # раніше collation_server = utf8_unicode_ci

collation-server=utf8_unicode_ci чи collation-server=utf8_general_ci? utf8_unicode_ci підтримує expansions на відміну utf8_general_ci, тобто вміє зіставляти один символ кільком (наприклад - у Німеччині ß = ss). Детальніше Unicode Character Sets.

Порівняння utf8_unicode_ci _ciбез урахування регістру, utf8_unicode_bin _binз урахуванням регістру.

Параметри my.cnf

> ee /etc/my.cnf # The following options will be passed to all MySQL clients #password = your_password port = 3306 socket = /tmp/mysql.sock # = /tmp/mysql.sock skip-locking key_buffer_size = 16M max_allowed_packet = 1M table_open_cache = 64 sort_buffer_size = 512K net_buffer_length = 8K read_buffer_size = 25K ffer_size = 8M default-character-set = utf8 character_set_server = utf8 collation_server = utf8_unicode_ci bind-address = 127.0.0.1 # Don't listen on a TCP/IP port at all. Unix sockets or named pipes.# All interaction with mysqld must be made via Unix sockets or named pipes. ! # #skip-networking #...

Конфігураційні параметри за умовчанням Mysql розраховані на невеликі бази даних, що працюють під малими наргузками на скромному залозі. Якщо Ваші плани щодо Mysql виходять за межі таблиць на кілька сотень записів, Вам обов'язково доведеться змінювати стандартні налаштування. Процес оптимального налаштування Mysql складається з двох частин початкове налаштуваннята коригування параметрів під час роботи. Коригування параметрів у робочому режимі багато в чому залежить від специфіки Вашої системи та її моніторингу – тут особливих правил немає. Для стартового налаштуванняє низка рекомендацій:

MySQL - вільна системауправління базами даних. Розробку та підтримку MySQLздійснює корпорація Oracle, яка отримала права на торгову маркуразом із поглиненою Sun Microsystems, яка раніше придбала шведську компанію MySQL AB. Продукт поширюється як під GNU General Public License, і під власною комерційною ліцензією. Крім цього, розробники створюють функціональність на замовлення ліцензійних користувачів, саме завдяки такому замовленню майже в самих ранніх версіяхвиник механізм реплікації.

Відкрийте файл налаштувань mysql, наприклад:

/etc/mysql/my.cnf

Симає поширені параметри, на які варто звернути увагу та змінити під Ваші вимоги:

key_buffer_size

Якщо Ви використовуєте тільки MyIsam таблиці, встановлюйте це значення в 30% ... 40% всієї доступної оперативної пам'ятіна сервері. MyIsam використовує кеш операційної системидля даних, тому врахуйте, що залишилася вільна пам'ятьзнадобиться саме для цього. Якщо ж MyIsam таблиць у Вас небагато і їхній сукупний розмір маленький - залиште це значення в межах 32M.

innodb_buffer_pool_size

Якщо Ви використовуєте лише InnoDB таблиці, встановлюйте це значення максимально можливим для Вашої системи. Буффер InnoDB кешує дані та індекси (а кеш операційної системи не використовується), тому значення цього ключа варто встановлювати в 70% ... 80% доступної пам'яті.

Якщо ваш сервер працює на лінкусі або юніксі, не забудьте встановити параметр innodb_flush_method у значення “O_DIRECT”, щоб уникнути кешування на рівні ОС того, що вже кешує Mysql.

innodb_log_file_size

Зверніть увагу на цей параметр, якщо Ви маєте великий показник записів. Чим більше розмірцього ключа, тим паче ефективно відбуватиметься запис даних. Але врахуйте, що збільшиться час відновлення системи! Цей параметр зазвичай встановлюють 64M-512M.

innodb_flush_log_at_trx_commit

Цей параметр значною мірою впливає на швидкість роботи (запису) в таблиці DB.
Значення "1" означає, що будь-яка завершена транзакція синхронно скидатиме лог на диск.
Значення "2" робить те саме, тільки скидає лог не на диск, а в кеш операційної системи. Це значення підійде здебільшого, т.к. не виконує дорогої операції запису після кожної транзакції. При цьому лог пишеться на диск із затримкою в кілька секунд, що дуже безпечно з точки зору збереження даних.
Значення "0" дасть найбільшу продуктивність. У цьому випадку буфер скидатиме в лог файл незалежно від транзакцій. Встановлюйте цей параметр "0" на свій ризик, т.к. у разі ризик втрати даних зростає.

table_cache

Цей ключ визначає пам'ять, що виділяється для зберігання відкритих таблиць. Якщо у Вас кілька сотень таблиць, встановлюйте це значення в 1024. Якщо ж у Вас величезна кількість з'єднань, поступово збільшуйте це значення, т.к. для кожного з'єднання зберігатиметься окремий запис.

thread_cache

Цей параметр допомагає уникнути операцій створення/знищення потоків під час з'єднання з сервером. Встановіть цей параметр 16 і нарощуйте в міру потреби. Перевіряйте показник “Threads_created”, ідеально він повинен дорівнювати нулю:

Mysql> show status like 'threads_created'; +-----–+--–+ | Variable_name | Value | +-----–+--–+ | Threads_created | 423312 | +-----–+--–+

query_cache_size

Значення цього параметра визначає, скільки пам'яті варто використовувати під кеш запитів. Не захоплюйтеся встановленням великих значень. Кеш запитів ні бути великим, т.к. mysql з'їдатиме ресурси на керування даними в кеші. Почніть з 32М ... 128М, і збільшуйте при необхідності.

10 серпня 2009 о 15:41

Що потрібно налаштувати в mySQL одразу після встановлення?

  • MySQL
  • Переклад

Вільний переклад досить старої статті з MySQL Performance Blog про те, що краще відразу налаштувати після встановлення базової версії mySQL.

Дивно, скільки народу встановлює mySQL на свої сервери і залишають його з налаштуваннями за умовчанням.

Незважаючи на те, що в mySQL існує досить багато налаштувань, які Ви можете змінити, є набір дійсно дуже важливих характеристик, які обов'язково потрібно оптимізувати під власний сервер. Зазвичай після такої невеликий налаштуванняпродуктивність сервера помітно зростає.

  • key_buffer_size- Вкрай важлива настройкапри використанні MyISAM-таблиць. Встановіть її близько 30-40% від доступної оперативної пам'яті, якщо використовуєте тільки MyISAM. Правильний розмірзалежить від розмірів індексів, даних та навантаження на сервер – пам'ятайте, що MyISAM використовує кеш операційної системи (ОС), щоб зберігати дані, тому потрібно залишити достатньо місця в ОЗП під дані, і дані можуть займати значно більше місця, ніж індекси. Однак обов'язково перевірте, щоб все місце, яке відводиться директивою key_buffer_sizeпід кеш, що постійно використовувалося - нерідко можна бачити ситуації, коли під кеш індексів відведено 4 ГБ, хоча загальний розмірвсіх.MYI-файлів не перевищує 1 ГБ. Робити так абсолютно марно, Ви тільки витратите ресурси. Якщо у Вас практично немає MyISAM-таблиць, то key_buffer_sizeслід виставити близько 16-32 МБ - вони будуть використовуватися для зберігання в пам'яті індексів тимчасових таблиць, що створюються на диску.
  • innodb_buffer_pool_size- не менш важливе налаштування, але вже для InnoDB, обов'язково зверніть на неї увагу, якщо збираєтеся використовувати в основному InnoDB-таблиці, т.к. вони значно чутливіші до розміру буфера, ніж MyISAM-таблиці. MyISAM-таблиці в принципі можуть непогано працювати навіть з великою кількістюданих та при стандартному значенні key_buffer_size, проте mySQL може сильно "гальмувати" при неправильному значенні innodb_buffer_pool_size. InnoDB використовує свій буфер для зберігання і індексів і даних, тому немає необхідності залишати пам'ять під кеш ОС - встановлюйте innodb_buffer_pool_sizeу 70-80% доступної оперативної пам'яті (якщо, звичайно, використовуються лише InnoDB-таблиці). Щодо максимального розміруданої опції - аналогічно key_buffer_size- не варто захоплюватися, потрібно знайти оптимальний розмір, знайдіть найкраще застосуваннядоступної пам'яті.
  • innodb_additional_mem_pool_size - дана опціяпрактично не впливає на продуктивність mySQL, але рекомендую залишати для InnoDB близько 20 МБ (або трохи більше) під різні внутрішні потреби.
  • innodb_log_file_size- Вкрай важливе налаштування в умовах баз даних з частими операціямизаписи в таблиці, особливо при великих обсягах. Б обільші розміри збільшують швидкодію, проте будьте обережні - збільшиться час відновлення даних. Я зазвичай виставляю значення близько 64-512 МБ, залежно від розміру сервера.
  • innodb_log_buffer_size - стандартне значенняданої опції цілком підійде для більшості систем із середньою кількістю операцій запису та невеликими транзакціями. Якщо ж у Вашій системі бувають сплески активності, або Ви активно працюєте з BLOB-даними, то рекомендую трохи збільшити значення innodb_log_buffer_size. Однак не перестарайтеся - занадто велике значеннябуде марною витратою пам'яті: буфер скидається кожну секунду, тому Вам не знадобиться більше місця, ніж потрібно протягом цієї секунди. Рекомендоване значення - близько 8-16 МБ, а для невеликих баз - і менше.
  • - скаржитесь, що InnoDB працює у 100 разів повільніше за MyISAM? Ймовірно, Ви забули про налаштування innodb_flush_log_at_trx_commit. Значення за умовчанням «1» означає, що кожна UPDATE-транзакція (або аналогічна команда поза транзакцією) повинна скидати буфер на диск, що є досить ресурсомістким. Більшість додатків, що особливо використовували таблиці MyISAM, будуть добре працювати зі значенням «2» (тобто «не скидати буфер на диск, тільки в кеш ОС»). Лог, однак, все одно скидатиметься на диск кожні 1-2 секунди, тому в разі аварії Ви втратите максимум 1-2 секунди оновлень. Значення «0» підвищить продуктивність, але Ви ризикуєте втратити дані навіть при аварійній зупинці сервера mySQL, у той час як при встановленні значення innodb_flush_log_at_trx_commitу «2» Ви втратите дані лише при аварії усієї операційної системи.
  • table_cache- Відкриття таблиць може бути дуже ресурсомістким. Наприклад, MyISAM-таблиці позначають заголовки. MYI файлів як «використовуються в поточний момент». Зазвичай не рекомендується відкривати таблиці занадто часто, тому краще, щоб кеш був достатніх розмірів, щоб тримати всі таблиці відкритими. Для цього використовується деяка кількість ресурсів ОС та оперативної пам'яті, проте це зазвичай не є суттєвою проблемою для сучасних серверів. Якщо у Вас кілька сотень таблиць, то стартовим значенням для опції table_cacheможе бути «1024» (пам'ятайте, що кожне з'єднання потребує власного дескриптора). Якщо у Вас ще більше таблицьабо багато з'єднань - збільште значення параметра. Я бачив mySQL серверазі значенням table_cacheрівною 100 000.
  • thread_cache- створення/знищення потоків також є ресурсомісткою операцією, яка відбувається при кожній установці з'єднання та кожному розриві з'єднання. Я зазвичай виставляю цю опцію рівну 16. Якщо у Вашої програми можуть бути скачки кількість конкурентних з'єднань і по змінній Threads_Createdвидно швидке зростання кількості потоків, то варто збільшити значення thread_cache. Ціль - не допускати створення нових потоків в умовах нормального функціонування сервера.
  • query_cache_size- якщо Ваша програма багато і часто читає дані, і при цьому у Вас немає кешу на рівні програми, ця опція може дуже допомогти. Не ставте тут надто велике значення, оскільки обслуговування великого кешу запитів буде саме собою витратним. Рекомендоване значення – від 32 до 512 МБ. Не забудьте перевірити, наскільки добре використовується кеш запитів – у деяких умовах (при невеликій кількості хітів у кеші, тобто коли практично не вибираються однакові дані) використання великого кешу може погіршити продуктивність.
Як Ви можете бачити, це - глобальні налаштування. Ці змінні залежать від «заліза» сервера і використовуваних двигунів mySQL, в той час як сесійні змінні зазвичай налаштовуються спеціально під конкретні завдання. Якщо Ви в основному використовуєте прості запити, то немає жодної необхідності збільшувати значення sort_buffer_sizeнавіть якщо у Вас є зайві 64 ГБ оперативної пам'яті. Більше того, великі значення кешів можуть лише погіршити продуктивність сервера. Сесійні змінні краще залишити на потім, для тонкого налаштування сервера.

PS: інсталяція mySQL йде з кількома встановленими файлами my.cnf, розрахованими під різне навантаження. Якщо Вам ніколи налаштовувати сервер вручну, то зазвичай краще використовувати їх, ніж стандартний конфігураційний файл, вибравши той, що більше підійде під навантаження сервера.

Налаштування MySQL зводиться, в основному, до редагування головного конфігураційного файлу (/etc/my.cnf FreeBSD). Перед налаштуванням слід врахувати, що у MySQL 5.6 назви деяких параметрів та їх наявність відрізняється від тих, які використовувалися у попередніх версіях.

MySQL 5.6 - конфігурація my.cnf

Для того, щоб зміни у файлі my.cnf набули чинності, необхідно перезавантажити сервер MySQL:

/usr/local/etc/rc.d/mysqld restart

Перевірити, чи сприйняті нові налаштування сервером, можна за допомогою запиту до БД:

mysql> SHOW WARIABLES;

Щоб переглянути лише певні установки, потрібно конкретизувати запит. Наприклад, щоб побачити параметр max_connections потрібно надіслати MySQL такий запит: mysql > SHOW VARIABLES LIKE "max _ conn% ";

Якщо після перезавантаження, зміни застосувалися частково або не сприймаються сервером MySQL, перевірте, чи можливо відредагований не той файл або MySQL додатково підвантажує інший конфігураційний файл, директиви якого перепризначають змінені вами параметри. Наприклад, при встановленні панелі керування хостингом DirectAdmin, сервер MySQL встановлюється автоматично і містить 2 конфігураційні файли: /etc/my.cnf і додатково підвантажується /usr/local/mysql/my.cnf. Змінюючи параметр sql_mode в /etc/my.cnf я довго не міг зрозуміти, чому він не застосовується до MySQL сервері, як виявилося, він перевизначався в /usr/local/mysql/my.cnf (FreeBSD) або /usr/my. cnf (CentOS). Як знайти список всіх файлів my.cnf, що використовуються в MySQL, можна подивитися, ввівши запит у пошуковій системі: "my.cnf location".

Повний список налаштувань, які використовуються в my.cnf, можна переглянути в офіційному посібнику користувача MySQL (eng), у колонці Option File.

Налаштування у розділі

local_infile

Цю змінну можна дозволити (ON або 1 - за замовчуванням) або заборонити (OFF або 0) використовувати LOCAL у запиті LOAD DATA. Якщо ви не знаєте точно, що це і навіщо потрібно, рекомендується переключити local_infile в OFF (local_infile=OFF ) з міркування безпеки сервера в цілому.

skip_external_locking

skip_external_locking - параметр, що відповідає за зовнішнє блокування файлів баз даних типу MyISAM (за замовчуванням встановлено в ON - блокування включене). Рекомендовано не змінювати цей параметр з міркувань швидкодії MySQL.

skip_name_resolve

Якщо параметр skip_name_resolve встановлений у ON або 1 (skip_name_resolve=OFF - за замовчуванням), то при зовнішньому підключенні MySQL сервер намагається перевести назву домену в IP-адресу, що помітно знижує швидкість обробки запиту. Для підвищення швидкодії, рекомендується встановити skip_name_resolve в OFF, в цьому випадку як хост при підключенні до MySQL можна буде використовувати тільки IP-адресу або localhost.

low_priority_updates

За промовчанням такі оператори MySQL як INSERT, REPLACE, UPDATE, DELETE мають більше високий пріоритетніж, наприклад, SELECT, і параметр low_priority_updates, відповідно, встановлений у OFF. Якщо сервер більше посилає запитів на читання, ніж зміна даних таблиць, можна встановити low_priority_updates в ON. Слід зазначити, що low_priority_updates застосовується лише до типів таблиць MyISAM, MEMORY та MERGE.

sql_mode

Від параметрів, вказаних у sql_mode, сильно залежить робота сервера MySQL. Неправильна вказівка ​​налаштувань може повністю зупинити роботу сайту, що використовує MySQL, призвести до вставлення некоректних параметрів у БД та інших проблем. Докладніше про sql_mod можна прочитати тут: , Server SQL Modes 5.6 (eng) .

За умовчанням, MySQL 5.6.6 і більше пізніх версіяхзначення sql_mode встановлено в NO_ENGINE_SUBSTITUTION ( sql_mode=NO_ENGINE_SUBSTITUTION), що буде достатньо для більшості сайтів, але все ж таки для розуміння роботи MySQLслід знати і про інші способи роботи MySQL, які задаються в sql_mode.

max_connections

Цей параметр відповідає за максимально-допустиму кількість одночасних підключеньдо MySQL. За замовчуванням його значення дорівнює 151 і може бути змінено в межах від 1 до 100 000. Збільшувати це значення слід, якщо з'являється помилка "Too many connections" або адміністратор впевнений, що значення за промовчанням буде не достатньо.

query_cache_type

Query_cache_type включає (ON) або вимикає (OFF) кешування запитів. Кешування - гарний спосібзменшити навантаження, якщо сервер обробляє багато однакових запитів. Використовувати query_cache_type слід практично завжди, за винятком випадків, коли запити MySQL кешує memcached.

query_cache_size

Розмір кешу запитів MySQL. Значення можна записати в Mb-query_cache_size=32M.

Налаштування для таблиць MyISAM

key_buffer_size

Якщо використовуються лише таблиці MyISAM, розмір буфера слід встановити у розмірі близько 30-35% від обсягу доступної оперативної пам'яті. Якщо ж MyISAM-таблиць дуже мало чи ні зовсім, то key_buffer_sizeможна встановити значення 32 МБ, місце використовуватиметься для зберігання в пам'яті індексів тимчасових таблиць, створюваних на диску. Вибір обсягу пам'яті для key_buffer_size залежить від розмірів індексів, даних та навантаження на сервер. Слід знати, що MyISAM використовує кеш операційної системи, щоб зберігати дані, тому потрібно залишити достатньо місця в ОЗУ під них. Дані можуть займати значно більше місця, аніж індекси. Однак варто перевірити, що вся пам'ять, вказана в key_buffer_size під кеш, постійно використовується, інакше це буде витрачання ресурсів у нікуди.

Установки для таблиць InnoDB

innodb_buffer_pool_size

innodb_buffer_pool_size- Розмір буфера таблиць InnoDB. Таблиці типу InnoDBвикористовують свій буфер для зберігання індексів та даних, тому немає необхідності залишати пам'ять під кеш операційної системи, встановлюйте innodb_buffer_pool_size у 75% доступної оперативної пам'яті, якщо планується використовувати лише таблиці з типом InnoDB. Рекомендації щодо максимального розміру даної опції аналогічні key_buffer_size для MyISAM: не варто встановлювати максимальний розмір, потрібно знайти оптимальний варіант, а доступною ОЗУможна знайти застосування та інших задачах.

  • Переклад

Вільний переклад досить старої статті з MySQL Performance Blog про те, що краще відразу налаштувати після встановлення базової версії mySQL.

Дивно, скільки народу встановлює mySQL на свої сервери і залишають його з налаштуваннями за умовчанням.

Незважаючи на те, що mySQL існує досить багато налаштувань, які Ви можете змінити, є набір дійсно дуже важливих характеристик, які обов'язково потрібно оптимізувати під власний сервер. Зазвичай після такого невеликого налаштування продуктивність сервера помітно збільшується.

  • key_buffer_size- дуже важлива настройка при використанні MyISAM-таблиць. Встановіть її близько 30-40% від доступної оперативної пам'яті, якщо використовуєте тільки MyISAM. Правильний розмір залежить від розмірів індексів, даних та навантаження на сервер – пам'ятайте, що MyISAM використовує кеш операційної системи (ОС), щоб зберігати дані, тому потрібно залишити достатньо місця в ОЗП під дані, і дані можуть займати значно більше місця, ніж індекси. Однак обов'язково перевірте, щоб все місце, яке відводиться директивою key_buffer_sizeпід кеш, постійно використовувалося – нерідко можна бачити ситуації, коли під кеш індексів відведено 4 ГБ, хоча загальний розмір всіх файлів MYI не перевищує 1 ГБ. Робити так абсолютно марно, Ви тільки витратите ресурси. Якщо у Вас практично немає MyISAM-таблиць, то key_buffer_sizeслід виставити близько 16-32 МБ - вони будуть використовуватися для зберігання в пам'яті індексів тимчасових таблиць, що створюються на диску.
  • innodb_buffer_pool_size- не менш важливе налаштування, але вже для InnoDB, обов'язково зверніть на неї увагу, якщо збираєтеся використовувати в основному InnoDB-таблиці, т.к. вони значно чутливіші до розміру буфера, ніж MyISAM-таблиці. MyISAM-таблиці в принципі можуть непогано працювати навіть з великою кількістю даних і за стандартного значення key_buffer_size, проте mySQL може сильно "гальмувати" при неправильному значенні innodb_buffer_pool_size. InnoDB використовує свій буфер для зберігання і індексів і даних, тому немає необхідності залишати пам'ять під кеш ОС - встановлюйте innodb_buffer_pool_sizeу 70-80% доступної оперативної пам'яті (якщо, звичайно, використовуються лише InnoDB-таблиці). Щодо максимального розміру даної опції – аналогічно key_buffer_size- не варто захоплюватися, потрібно знайти оптимальний розмір, знайдіть найкраще застосування доступної пам'яті.
  • innodb_additional_mem_pool_size- ця опція практично не впливає на продуктивність mySQL, але рекомендую залишати для InnoDB близько 20 МБ (або трохи більше) під різні внутрішні потреби.
  • innodb_log_file_size- Вкрай важлива настройка в умовах баз даних з частими операціями запису в таблиці, особливо при високих обсягах. Б обільші розміри збільшують швидкодію, проте будьте обережні - збільшиться час відновлення даних. Я зазвичай виставляю значення близько 64-512 МБ, залежно від розміру сервера.
  • innodb_log_buffer_size- Стандартне значення даної опції цілком підійде для більшості систем із середньою кількістю операцій запису та невеликими транзакціями. Якщо ж у Вашій системі бувають сплески активності, або Ви активно працюєте з BLOB-даними, то рекомендую трохи збільшити значення innodb_log_buffer_size. Однак не перестарайтеся - занадто велике значення буде марною тратою пам'яті: буфер скидається кожну секунду, тому Вам не знадобиться більше місця, ніж потрібно протягом цієї секунди. Рекомендоване значення - близько 8-16 МБ, а для невеликих баз - і менше.
  • - скаржитесь, що InnoDB працює у 100 разів повільніше за MyISAM? Ймовірно, Ви забули про налаштування innodb_flush_log_at_trx_commit. Значення за умовчанням «1» означає, що кожна UPDATE-транзакція (або аналогічна команда поза транзакцією) повинна скидати буфер на диск, що є досить ресурсомістким. Більшість додатків, що особливо використовували таблиці MyISAM, будуть добре працювати зі значенням «2» (тобто «не скидати буфер на диск, тільки в кеш ОС»). Лог, однак, все одно скидатиметься на диск кожні 1-2 секунди, тому в разі аварії Ви втратите максимум 1-2 секунди оновлень. Значення «0» підвищить продуктивність, але Ви ризикуєте втратити дані навіть при аварійній зупинці сервера mySQL, у той час як при встановленні значення innodb_flush_log_at_trx_commitу «2» Ви втратите дані лише при аварії усієї операційної системи.
  • table_cache- Відкриття таблиць може бути дуже ресурсомістким. Наприклад, MyISAM-таблиці позначають заголовки. MYI файлів як «використані зараз». Зазвичай не рекомендується відкривати таблиці занадто часто, тому краще, щоб кеш був достатніх розмірів, щоб тримати всі таблиці відкритими. Для цього використовується деяка кількість ресурсів ОС та оперативної пам'яті, проте це зазвичай не є суттєвою проблемою для сучасних серверів. Якщо у Вас кілька сотень таблиць, то стартовим значенням для опції table_cacheможе бути «1024» (пам'ятайте, що кожне з'єднання потребує власного дескриптора). Якщо у Вас ще більше таблиць або багато з'єднань - збільште значення параметра. Я бачив mySQL сервера зі значенням table_cacheрівною 100 000.
  • thread_cache- створення/знищення потоків також є ресурсомісткою операцією, яка відбувається при кожній установці з'єднання та кожному розриві з'єднання. Я зазвичай виставляю цю опцію рівну 16. Якщо у Вашої програми можуть бути скачки кількість конкурентних з'єднань і по змінній Threads_Createdвидно швидке зростання кількості потоків, то варто збільшити значення thread_cache. Ціль - не допускати створення нових потоків в умовах нормального функціонування сервера.
  • query_cache_size- якщо Ваша програма багато і часто читає дані, і при цьому у Вас немає кешу на рівні програми, ця опція може дуже допомогти. Не ставте тут надто велике значення, оскільки обслуговування великого кешу запитів буде саме собою витратним. Рекомендоване значення – від 32 до 512 МБ. Не забудьте перевірити, наскільки добре використовується кеш запитів – у деяких умовах (при невеликій кількості хітів у кеші, тобто коли практично не вибираються однакові дані) використання великого кешу може погіршити продуктивність.
Як Ви можете бачити, це – глобальні налаштування. Ці змінні залежать від «заліза» сервера і використовуваних двигунів mySQL, тоді як сесійні змінні зазвичай налаштовуються спеціально під конкретні завдання. Якщо Ви в основному використовуєте прості запити, то немає необхідності збільшувати значення sort_buffer_sizeнавіть якщо у Вас є зайві 64 ГБ оперативної пам'яті. Більше того, великі значення кешів можуть лише погіршити продуктивність сервера. Сесійні змінні краще залишити на потім, для тонкого налаштування сервера.

PS: інсталяція mySQL йде з кількома встановленими файлами my.cnf, розрахованими під різне навантаження. Якщо Вам ніколи налаштовувати сервер вручну, то зазвичай краще використовувати їх, ніж стандартний конфігураційний файл, вибравши той, що більше підійде під навантаження сервера.