Я готовий перейти від MyISAM до InnoDB, але хотів дізнатися, чи є повний перелік речей, які потрібно шукати? Наприклад, я не бачив жодного списку, в якому згадується, що біг DISABLE KEYSза таблицею InnoDB видасть попередження, за винятком сторінки вручну для ALTER TABLE. Це та річ, про яку я повинен знати, перш ніж перетворювати. Я думав, що я буду добре зі своїми запитами, але, мабуть, ні.

Ось кілька готчей

Використання пам'яті

MyISAM

• кешує лише індексні сторінки.
• спільний кеш-пам'ять (розмір за розміром key_buffer_size).
• Ви також можете встановити спеціальний кеш-пам'ять, одну або кілька таблиць на кеш-таблиці .

InnoDB

• кешує сторінки даних та сторінки покажчиків.
• один буферний пул і один розмір перед MySQL 5.5
• 1 або більше буферних пулів, починаючи з MySQL 5.5

Ось декілька запитів, які я писав і розміщував раніше про те, як вибрати належний розмір кешу MyISAM Key і буфера InnoDB .

Індекси FULLTEXT

MyISAM

• Підтримує індекси FULLTEXT

InnoDB

• Починаючи з MySQL 5.6, так, але все ще в бета-версії (ОНОВЛЕННЯ: MySQL 5.6 існує і має індекси FULLTEXT. Якщо ви використовуєте індексацію FULLTEXT в MySQL 5.6, переконайтеся, що ви використовуєте специфічні для InnoDB параметри FULLTEXT )
• Перед MySQL 5.6 це означає, що ви не можете конвертувати MyISAM в InnoDB.

MySQL 5.5 і назад

Щоб знайти, які таблиці MyISAM мають індекс FULLTEXT, запустіть цей запит:

select tbl.table_schema,tbl.table_name from
(
    select table_schema,table_name
    from information_schema.tables
    where engine='MyISAM'
    and table_schema NOT IN ('information_schema','mysql')
) tbl
INNER JOIN
(
    select table_schema,table_name
    from information_schema.statistics
    where index_type='FULLTEXT'
) ndx
USING (table_schema,table_name);

Що б вийшло з цього запиту, не можна перетворити на InnoDB, поки ви не оновите до MySQL 5.6.

ОПТИМІЗУЙТЕ ТАБЛИЦЮ

MyISAM

• Таблиця MyISAM скорочується
• ANALYZE TABLE веде статистику індексів по всіх індексах

InnoDB

• ТАБЛИКА АНАЛІЗУ абсолютно марна, тому що статистика індексу завжди пригадується
• Якщо вимкнено innodb_file_per_table , ibdata1 буде зростати
• З innodb_file_per_table включений, файл табличного (.ibd) вмощується

Я думаю, що найбільша проблема - це трансакція innodb. Ви хочете знати, чи використовуються бібліотеки MySQL, які використовуються вашими програмами auto_commit за замовчуванням чи ні.

Наприклад, Python не здійснює автоматичне здійснення. Це означає, що якщо програма вставляла рядок безпосередньо перед закриттям з'єднання, тепер вставлення буде повернуто після зміни іннодб. Наприклад, сценарій python повинен бути обов'язково зателефонував на connection.commit ();

Ще одна відмінність може полягати у вставці чи оновленнях з декількома рядками. Розглянемо одну вставку з декількома рядами

insert into tbl values (...row1...),  (...row2...),  (...rowN....);

Поміркуйте, що станеться, якщо в рядку3 є якась помилка, наприклад унікальне зіткнення ключа. З MyISAM були б написані перші два ряди, під innodb всі рядки, що записуються, будуть повернуті назад, не залишаючи нічого подібного в помилках.

З innodb ви увійдете у світ тупиків. Вони не є по суті поганими, якщо вони не трапляються з такою частотою, щоб не допустити будь-якої роботи. Однак ваші програми потребують кодування таким чином, що вони передбачають тупикові місця та обробляють їх належним чином (що, швидше за все, означає просто повторити).

Розглянемо обмеження пам'яті / зберігання. Innodb набагато більш ресурсомісткий, ніж MyISAM. Якщо у вас є достатня кількість оперативної пам’яті, щоб зберегти буферні пули досить великими, щоб вмістити всі ваші таблиці, то ви золото.

Шукайте таблиці з великими первинними ключами. Кластерована індексація Innodb означає, що кожен вторинний індекс містить ще одну копію ПК відповідного рядка. Якщо у вас є 2 вторинні індекси, це означає, що кожен рядок ПК зберігається 3 рази (PK + кожен індекс). Якщо pk охоплює декілька стовпців і великі типи даних (наприклад, char (N)), ви можете побачити, як вимоги до індексу можуть швидко вибухнути під innodb.