У мене є велика таблиця (кілька 100 мільйонів рядків), яку я хотів би ефективно розділити. Моє запитання - чи існує компроміс між розміром розділу та кількістю розділів. Наскільки я розумію, більшість запитів на стовпчик, що використовується в розділі, буде швидше, оскільки запит (для більшості запитів) повинен шукати лише в розділі, застосовному до запиту. Таким чином, було б сенс, що для досягнення максимальної ефективності слід розділити велику таблицю на максимальну кількість розділів, отже, зробивши кожен розділ якомога меншим. У випадку з MySQL це означає 1024 розділи. Але чи є недолік продуктивності у наявності великої кількості розділів? Так, як можна знайти оптимальну кількість розділів?

Примітка. У stackoverflow вже є дещо подібне запитання , але лише одна відповідь, яка (з моєї точки зору) не вистачає позначки. Тож я поставлю це питання по-своєму ... сподіваюся, це більш зрозуміло

Давайте порівняємо їх

РОЗМІР РОЗДІЛУ

Якщо у вас є таке:

• 100 мільйонів рядків у таблиці
• BTREE індексація
• Кожна Сторінка в BTREE містить 1024 клавіші

Як виглядали б показники?

Оскільки LOG (100000000) / LOG (2) = 26.575424759099, індекс BTREE з 1024 клавішами на треноді сторінки має висоту дерева лише 3 (CEILING (LOG (100000000) / LOG (1024))). Маючи лише три вузли сторінки, двійковий пошук потрібного ключа у кожному доступному треноді призведе до обрізки та виділення приблизно 30 клавіш.

КІЛЬКА СТОРІН

Якщо у вас є таке:

• 100 мільйонів рядків у таблиці
• BTREE індексація
• Кожна Сторінка в BTREE містить 1024 клавіші
• Ви створюєте 1024 розділів

Цифри будуть дещо різними.

Кожен розділ повинен мати приблизно 97656 рядків. Якими стали б показники зараз?

Оскільки LOG (97656) / LOG (2) = 16.575421065795, індекс BTREE з 1024 клавішами на треноді сторінки має висоту дерева лише 2 (CEILING (LOG (97656) / LOG (1024))). Маючи лише дві сторінки на сторінках, двійковий пошук потрібного ключа в кожному доступному треноді призведе до обрізки та виділення приблизно 20 клавіш.

ВИСНОВОК

Розгортання клавіш просто видаляє один рівень дерева, але по суті створює 1024 індекси. Запити не знають різниці. Час пошуку, мабуть, буде номінальним у кращому випадку на користь розділів. Однак переконайтеся, що всі дані активні. З іншого боку, ви можете потрапляти лише на кілька розділів, тоді як інші розділи з рідко доступними даними просто займають простір і ніколи не доступні досить часто, щоб виправдати розділення . Можливо, у вас є різні показники продуктивності, для яких можна потурбуватися про більш чіткі (наприклад, внутрішня дефрагментація в XFS , ext3 vs ext4 тощо). Вам також потрібно потурбуватися про те, який механізм зберігання даних ви використовуєте, оскільки:

• Індексація InnoDB виявилася б трохи мізерною порівняно з MyISAM через те, що потрібно керувати кластерним індексом
• InnoDB робить подвійне записування даних у ibdata1, а також у поточний файл журналу (ib_logfile0 або ib_logfile1)