Чи є звичайною практикою змішування таблиць InnoDB та MyISAM на одному сервері?


21

У мене єдина база даних близько 4,5 ГБ, яка працює на сервері з 8 ГБ ОЗУ. Переважна більшість таблиць - MyIsam (близько 4,3 ГБ), але я скоро збираюся перетворити деякі з них на InnoDB. (Це буде повільним процесом, спочатку зосередившись на найінтенсивніших таблицях).

Чи є щось погано в запуску виділеного сервера, на якому існують обидва типи двигунів зберігання даних?


Is there anything wrong with running a dedicated server where both types of storage engines exist? Може перефразовувати Multiple types?
Іоанна

Єдина причина, по якій я сказав «обидва», полягає в тому, що це питання стосується двох основних двигунів, налаштованих на «тонку настройку». Я намагаюся ігнорувати інші типи двигунів, як MEMORY або MERGE, які досить рідкісні, що afaik не є об'єктом настройки продуктивності.
Дерек Дауні

Відповіді:


18

У тому, що ви розумієте плюси і мінуси кожної фізичної машини, немає нічого поганого в тому, щоб використовувати декілька двигунів зберігання даних на одній фізичній машині. Існують міркування щодо продуктивності, обмеження функцій та випадки використання для всіх типів зберігання плагінів.

Наприклад, якщо у вас невелика таблиця, на якій написано 90%, ви можете вибрати MyISAM. Якщо дані можна легко регенерувати і це невелика таблиця, скажімо, для черги, ви можете обрати Пам'ять. Якщо у вас є таблиця, яка на 90% читає, і дані повинні бути там, коли ви шукаєте їх, то ви, мабуть, обрали двигун зберігання даних, який підтримує транзакції та налаштовується атомність, наприклад InnoDB. Якщо ви хочете отримати доступність через файлову систему без пошкодження даних, ви можете вибрати CSV.

Тим не менш, ви можете безпечно використовувати декілька двигунів зберігання даних в одній схемі, а також фізичний хост.

Дозвольте мені зазначити, що ваші буфери грають роль у всьому цьому безладі. Якщо ви використовуєте MyISAM та InnoDB, вам потрібно бути обережними, щоб ваш key_buffer та innodb_buffer_pool не суперечилися. Це потребує ретельного планування з вашого боку, але це ми робимо.


4
+1 Ще один поширений випадок використання - MyISAM для таблиць, які потребують повного пошуку тексту та InnoDB для всіх інших таблиць.
Асаф

@Aseph: Ще під час Вашого коментаря InnoDB підтримував індекси Fulltext .
BlueRaja - Danny Pflughoeft

2
^^^^ "Особливості MySQL 5.6" не було GA до 2013-02-05
випадковий

1
@randymelder Приємна відповідь. Чи зможете ви детальніше розібратися з тим, що ви мали на увазі під «Ви повинні бути обережними, щоб ваші key_buffer та innodb_buffer_pool не суперечили»?
Ніл

1
Я хочу, щоб я був неправдивим, але логіка виглядає навпаки цій stackoverflow.com/a/6796566/5645769 тут.
Tᴀʀᴇǫ Mᴀʜᴍᴏᴏᴅ

7

Я не можу вам сказати, чи це звичайна практика. Я можу сказати про власний досвід.

Я завжди використовую найкращий інструмент для роботи, тому весь час перемішую двигуни. Більшість моїх проектів використовують MyISAM як двигун за замовчуванням.

Коли мені потрібні спеціальні функції, просто доступні в InnoDB, я переходжу до цього.

Коли таблиця здебільшого лише для читання, я вибираю движок Archive, перш ніж я можу моргати.

Знаючи, що машинному серверу достатньо пам’яті, всі мої темп-дані зберігаються в таблицях Heap.

У минулому я бачив деякі уповільнення змішування MyISAM та InnoDB, але це не конкретна проблема MySQL. Це проблема дизайну, яка не здається, коли ви використовуєте лише один двигун. Насправді використання неправильного двигуна спричиняє більше уповільнення не має значення, якщо це просто MyISAM, просто InnoDB або суміш обох. Важко визначити формулу, щоб знати, коли відбудеться уповільнення. Просто фактичні тести можуть сказати вам це.

Звичайно, ви не змогли зберегти цілісність та послідовність змішування InnoDB та MyISAM за унікальним запитом.


архіватор не підтримує індексацію, тому чому ви зберігаєте його в архіві.
user4951

0

Я намагаюся уникати змішування таблиць MyISAM та InnoDB в одній базі даних, але це з розуму, а не з практичних причин. Однак мені здається корисним мати базу даних із таблицями MyISAM для повнотекстового пошуку, щоб я міг запускати це на сайтах. Зберігання його в окремій базі даних із іноземним ключем для кожного запису спрощує будь-яким іншим розробникам, які працюють над БД, бачити, що відбувається.


Як у вас можуть бути іноземні ключі, коли ви використовуєте MyISAM?
a_horse_with_no_name

Неправильна термінологія, але працює як іноземний ключ. Я зберігаю ідентифікаційний номер елемента з таблиці InnoDB і використовую його для пошуку сторінки в результатах пошуку.
Кензо
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.