Найкраще з MyISAM та InnoDB

Чи можна змусити InnoDB використовувати такі ж показники, як MyISAM, замість кластеризованого індексу через обмеження оперативної пам’яті, отримуючи переваги від її одночасності?

Gen_clust_index (кластерний індекс) під капотом InnoDB будинків записи первинних ключів разом з ROWIDs. Що цікавого щодо використання gen_clust_index - це той факт, що будь-які створені не унікальні індекси завжди матимуть відповідний рядок для gen_clust_index таблиці. Таким чином, завжди є подвійні пошукові індекси, один для вторинного індексу та один для gen_clust_index.

Будь-які спроби покращити компонування таблиці або первинного ключа анулюються через gen_clust_index або принаймні граничні результати в кращому випадку.

ПРИКЛАД

Деякі люди намагаються сортувати MyISAM в порядку PRIMARY KEY. Відповідно до проектування та налаштування бази даних MySQL, пункт 23, підрозділ "Зберігання таблиці в порядку індексу":

Якщо ви часто отримуєте великі діапазони індексованих даних із таблиці або послідовно сортуєте результати за одним і тим же індексним ключем, можливо, ви захочете розглянути можливість запуску myisamchk за допомогою параметра --sort-records. У цьому випадку скажіть MySQL сортувати дані таблиці в тому ж фізичному порядку, що й індекс, і це може допомогти прискорити такі операції. Крім того, ви можете комбінувати оператор ALTER TABLE з ЗАМОВЛЕННЯМИ за певним параметром стовпця, щоб досягти однакових результатів.

Зрозуміло, це працює і ефективно працює для MyISAM . Ви можете виконати ALTER TABLE ... ORDER BY col1, col2, ..., coln проти InnoDB, де стовпці можуть бути, а не бути такими, як PRIMARY KEY. Це не дасть більш швидких результатів для InnoDB, оскільки ... це правильно ... ви повинні кожен раз звертатися до gen_clust_index.

Деякі люди можуть створити формат рядків таблиці ФІКСОВАНО за допомогою ALTER TABLE mydb.mytb ROW_FORMAT=Fixed;та можуть отримати на 20% збільшення продуктивності читання без будь-яких інших змін. Це працює і ефективно працює для MyISAM . Це не дасть більш швидких результатів для InnoDB, оскільки ... це правильно ... ви повинні кожен раз звертатися до gen_clust_index.

Ви можете виконати наступне в таблиці InnoDB під назвою mydb.mytb:

CREATE TABLE mydb.mytc LIKE mydb.mytb;
INSERT INTO mydb.mytc SELECT * FROM mydb.mytb ORDER BY col1,col2,...coln;
ALTER TABLE mydb.mytb RENAME mydb.mytd;
ALTER TABLE mydb.mytc RENAME mydb.mytb;
DROP TABLE mydb.mytd;

Це приведе таблицю в рядковий порядок у gen_clust_index. Це може призвести до кращих результатів для InnoDB в кращому випадку, тому що ... це правильно ... ви повинні кожен раз звертатися до gen_clust_index.

Тепер давайте трохи смішно. Існує інтерфейс NoSQL для запиту (тільки SELECT) MyISAM та InnoDB під назвою інтерфейс HandlerSocket (раніше називався HANLDER) . Це дає вам доступ до даних, що дозволяє обходити всі протоколи SQL, ACID та MVCC . Хоча це можливо, ІМХО СПОСОБ ЗАВЕРШЕНО КОДУВАННЯ ТА ПОДАЄТЬСЯ. AFAIK не містить нічого в друку, вказуючи, чи взаємодіє інтерфейс HandlerSocket з gen_clust_index чи ні.

Підводячи підсумок, існує безліч способів шкіряти кішку. У цьому випадку ви не можете влаштувати кішку (gen_clust_index). Я думаю, що саме тому MyISAM продовжує існувати для своєї продуктивності читання, надійності в упорядкуванні таблиць, формату рядків таблиці та інструментів для її підтримки. InnoDB буде залишатися розробленою навколо своєї сумісної з ACID природою, поки якась хоробра душа не візьме вихідний код InnoDB і не перетворить його на щось найкраще як для MyISAM, так і для InnoDB .

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

Доступ до рядка через кластерний індекс швидкий, оскільки дані про рядки знаходяться на тій самій сторінці, куди веде пошук індексу. Якщо таблиця велика, кластеризована архітектура індексу часто зберігає операцію вводу / виводу диска в порівнянні з організаціями зберігання, які зберігають дані про рядки, використовуючи іншу сторінку від запису індексу. (Наприклад, MyISAM використовує один файл для рядків даних, а інший - для записів індексу.)

Дисковий ввід / вивід коштує дорого. Тож зменшення цього є величезною перевагою для покращення одночасності.

Якщо введення / виведення диска починає дешевшати і менше вузького місця (наприклад, у міру того, як технологія SSD стає більш стабільною), Oracle може вирішити змінити, як працюють індекси InnoDB. Швидше за все, він залишиться тим самим, оскільки та сама технологія зробить «обмеження оперативної пам’яті» меншим питанням.

Коротка відповідь: Ні.

InnoDB кластеризується через первинний ключ, а за відсутності первинного ключа він вибирає перший унікальний індекс. За відсутності унікального індексу, він створює прихований 6-байтний ключ для кластеризації.

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

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

Це правда, але одне втіху полягає в тому, що комерційні бази даних намагаються зробити свої дерева максимально жирними, а не глибокими. Спробуйте запустити xtrabackup --stats на своїх даних, щоб побачити. Наприклад:

<INDEX STATISTICS>
  table: test/table1, index: PRIMARY, space id: 12, root page 3
  estimated statistics in dictionary:
    key vals: 25265338, leaf pages 497839, size pages 498304
  real statistics:
     level 2 pages: pages=1, data=5395 bytes, data/pages=32%
     level 1 pages: pages=415, data=6471907 bytes, data/pages=95%
        leaf pages: recs=25958413, pages=497839, data=7492026403 bytes, data/pages=91%

Було 497839 аркушів аркушів (~ 8 Гб), але лише 416 сторінок вище (6,5 МБ). Я кілька разів запускав цю команду щодо виробничих даних, і це мене завжди дивує, коли у мене є мільйони мільярдів записів, і лише рівень 1-3 сторінки + сторінки аркушів.