key_buffer_size, innodb_buffer_pool_size - але комент.
innodb_log_file_size - залежить від необхідного вам об'єму даних для відновлення, але 256Мб будуть розумним компромісом між продуктивністю і Рамер лог-файлу.
innodb_log_buffer_size - значення за замовчуванням цілком підійде для більшості проектів із середньою інтенсивністю записи і короткими транзакціями. Однак якщо у вас бувають піки активності або робота з великим об'ємом даних, ви, ймовірно, захочете збільшити значення цього параметра. Не робіть його занадто великим, це спричинить зайва витрата пам'яті. Буфер скидається кожну секунду і вам не потрібен більший обсяг пам'яті. Зазвичай цілком вистачає 8 - 16МB. Чим менше система - тим менше повинно бути значення.
innodb_flush_log_at_trx_commit - Вам здається, що InnoDB в сто разів повільніше MyISAM? Ймовірно, ви забули змінити значення цього параметра. Значення за замовчуванням 1 означає, що після кожної завершеної транзакції (або після зміни стану транзакції) лог повинен бути скинутий на диск. Це досить дорога операція, особливо якщо у вас немає Battery backed up cache. Багато додатків, особливо ті, в яких раніше використовувався MyISAM будуть добре працювати при значенні 2. який означає, що не треба скидати буфер на диск, а слід відправити його в кеш операційної системи. Лог як і раніше буде скидатися на диск кожну секунду і максимум, що ви можете втратити - це 1-2 секунди записів. Значеніе0 забезпечує більш високу швидкість, але і більш низьку надійність.
innodb_log_file_size - залежить від необхідного вам об'єму даних для відновлення, але 256Мб будуть розумним компромісом між продуктивністю і Рамер лог-файлу
innodb_log_buffer_size = 4M - 4 мегабайта - нормальне значення, якщо ви не використовуєте подачу великих блоків даних в InnoDB через канали (pipes). Якщо використовуєте, це значення краще збільшити.
innodb_thread_concurrency = 8 - навіть при наявних InnoDB Scalability Fixes буде зовсім не зайвим мати обмежена кількість потоків. Значення може бути більше або менше в завісомості від ваших потреб, але 8 буде оптимальним значенням для початку.
innodb_flush_method = O_DIRECT - уникайте подвійний буферизації і зменшіть активність swap, в більшості випадків це збільшує продуктивність. Але будьте обережні, якщо у вас немає RAID з можливістю збереження даних, операції введення-виведення можуть проходити некоректно і дані можуть бути пошкоджені.
innodb_file_per_table - якщо у вас трохи таблиць, використовуйте цю опцію і зростання займаного таблицями місця не буде безконтрольним. Ця опція додана в MySQL 4.1 і зараз досить стабільна для використання.
Перевірте також, чи можуть ваші програми запускатися в режимі ізоляції READ-COMMITED. Якщо це так, то встановіть опцію transaction-isolation = READ-COMITTED. Цей варіант збільшить продуктивність.
Вимкніть подвійну буферизацію: На Linux, FreeBSD, Solaris вам потрібно задати параметр innodb_flush_method = O_DIRECT.
read_buffer_size = 64K - 128K
Created_tmp_disk_tables - phpMtAdmin пише: "При великому значенні змінної рекомендується збільшити розмір кеша таблиць (table_cache)." Тут є два моменти
1) tmp_table_size і max_heap_table_size повинні бути рівні, оскільки обидва ці механізму беруть участь в створенні тимчасових таблиць.
2) Чи не робимо tmp_table_size і max_heap_table_size занадто великими, оскільки надмірне збільшення, з одного боку, може уповільнити роботу, а з іншого, не дати ефект оскільки, згідно з документацією, тимчасові таблиці не можуть бути створені в пам'яті коли в запиті є TEXT або BLOB.
Швидше за все, в цьому випадку потрібно спробувати створити файлову систему в пам'яті mfs і перепризначити в my.cnf на неї tmpdir.
Ця опція не може бути ніяк пропущена, якщо у вас серйозне навантаження на конкурентну запис. Дуже складно це пояснити, та й не розумію я цього до самої глибини, але якщо коротко ...
Якщо вам потрібна повноцінна ізоляція транцакцій, то ця опція не для вас. Тоді доведеться нехтувати продуктивністю на користь цілісності транзакцій.
Наприклад, якщо ви використовуєте читання за діапазоном (SELECT a FROM b WHERE c> 100) всередині тразакціі, то з включеною опцією innodb_locks_unsafe_for_binlog, наступний такий же запит поверне той же результат, навіть якщо між ними хто то що то в цю таблицю намагався писати.
При вимкненому (за замовчуванням) опції innodb_locks_unsafe_for_binlog, вдруге вказаний запит може повернути відмінний від першого разу результат в одній транзакції, оскільки намагаються писати в цю таблицю процесам не було виставлено перешкод.
Тобто, ця опція у включеному стані знімає туеву хучу локов при конкурентній записи-читанні в таблиці. Ціна питання - не забезпечується сумісний снапшот даних на час всієї транзакції. Як то так в загальному.
У моєму випадку, приріст продуктивності при включенні цієї опції був колосальний. Однак це має сенс на реально масивних змішаних записах-удалениях-читаннях.
Ах да. І для реплікації відповідно це не канал.