MySQL - чому б не індексувати кожне поле?

Нещодавно я дізнався про чудеса показників, а продуктивність значно покращилась. Однак, маючи все, що я дізнався, я не можу знайти відповідь на це питання.

Індекси чудові, але чому хтось не міг просто проіндексувати всі поля, щоб зробити таблицю неймовірно швидкою? Я впевнений, що є вагомі причини цього не робити, але як щодо трьох полів у таблиці з тридцятьма полями? 10 у полі 30? Де слід проводити лінію і чому?

Індекси займають місце в пам'яті (ОЗП); Занадто багато або занадто великих індексів, і БД доведеться міняти їх на диск і з нього. Вони також збільшують час вставки та видалення (кожен індекс повинен бути оновлений для кожного фрагмента даних, вставлених / видалених / оновлених).

У вас немає нескінченної пам’яті. Зробити це так, щоб усі індекси вмістилися в ОЗУ = добре.

У вас немає нескінченного часу. Індексація лише потрібних вам індексованих стовпців мінімізує звернення ефективності вставки / видалення / оновлення.

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

Крім того, кожен індекс займає додатковий простір на диску та простір пам’яті (коли він викликається), тому він може потенційно уповільнити операції з читання (також для великих таблиць). Заціни

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

Індексація займе більше виділеного простору як від накопичувача, так і від оперативної пам'яті, але також значно покращить продуктивність. На жаль, коли вона досягне межі пам’яті, система здасть провідний простір і ризикує продуктивністю. Практично ви не повинні індексувати жодне поле, яке, на вашу думку, не передбачає жодного алгоритму переходу даних, ані вставки, ані пошуку (пункт WHERE). Але вам слід, якщо інше. За замовчуванням потрібно проіндексувати всі поля. Поля, які слід розглянути як нерозбірник, - це якщо запити використовує лише модератор, за винятком випадків, якщо вони також потрібні для швидкості

ця відповідь є моєю особистою думкою, я використовую свою математичну логіку для відповіді

друге питання стосувалося межі, де зупинитися. Спочатку давайте зробимо математичний розрахунок, припустимо, у нас N рядків з L полями, якщо індексувати всі поля, ми отримаємо L нових таблиць індексів, де кожна таблиця буде сортована у значущим чином дані поля індексу, на перший погляд, якщо ваша таблиця має вагу W, вона стане W * 2 (1 тера стане 2 тера), якщо у вас є 100 великих таблиць (я вже працював у проекті, де номер таблиці був близько 1800 таблиці) Ви витратите 100 разів більше місця (100 тера), це далеко не розумно.

Якщо ми будемо застосовувати індекси у всіх таблицях, нам доведеться подумати про оновлення індексу, якщо це було одне тригер оновлення, оновлення всіх індексів - це виділення всіх не упорядкованих еквівалентів у часі

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

що індексувати?

іноземні ключі: базується на

первинний ключ: Я ще не впевнений у цьому, можливо, якщо хтось прочитає це, може допомогти у цій справі

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

З цього 3 пункту я можу зробити висновок, що якщо у нас є поля L, що складаються з клавіш K, то межа має бути дещо ближчим ((L-K)/2)+Kдо L / 10

ця відповідь ґрунтується на моїй логіці та особистих підказках

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