Разбиране на индексите в MySQL:Част втора

Тази публикация в блога е втората част от поредицата блогове за индекси в MySQL. В първата част от поредицата от публикации в блога за MySQL индексите, ние покрихме доста неща, включително какво представляват, какво правят, какви са техните типове, как да избирате оптимални типове данни и набори от символи на MySQL за индекси, които използвате . Прегледахме предимствата и недостатъците на използването на индекси в MySQL; казахме ви как да изберете най-добрия индекс за използване, как да подобрите производителността на заявката и да се уверите, че MySQL използва вашите индекси, колко индекса трябва да имате. Минахме и през някои съображения, свързани с двигателите за съхранение. Тази публикация в блога ще разгледа по-подробно някои от съдържанието, което обсъдихме в първата част от поредицата. Ще започнем с корелацията между индексите и механизмите за съхранение в MySQL.

Индекси и машини за съхранение в MySQL

Както вече споменахме в предишна публикация в блога, може да има някои видове ограничения за индекси и други неща, ако използвате определени машини за съхранение в MySQL. Ето някои от тях - сега ще дефинираме какви са някои от тях (някои от тях бяха разгледани в първата част от поредицата от блогове, така че ако пропуснем нещо, то вероятно е там), след това ги покрийте с по-задълбочено анализ:

Съгласно документацията на MySQL, максималният брой индекси, максималната дължина на ключа и максималната дължина на индекса са дефинирани за машина за съхранение. Както вече споменахме в предишна публикация в блога, максималният брой индекси за MyISAM и InnoDB таблици е 64, максималният брой колони на индекс и в двете системи за съхранение е 16, максималната дължина на ключа за InnoDB е 3500 байта, а максималната дължината на ключа за MyISAM е 1000 байта.
Не можете да използвате CREATE INDEX за създаване на ПЪРВИЧЕН КЛЮЧ - вместо това използвайте ALTER TABLE.
Колоните BLOB и TEXT могат да бъдат индексирани само за таблици, работещи с двигателите за съхранение InnoDB, MyISAM и BLACKHOLE.
Ако индексирате само префикс на колоната, имайте предвид, че поддръжката на префикса и тяхната дължина също са зависи от двигателите за съхранение. Префиксът може да бъде с дължина до 767 байта за таблици InnoDB, които използват РЕДУНДАНТЕН или КОМПАКТЕН формат на ред, но за DYNAMIC или COMPRESSED формати на ред ограничението за дължина на префикса се увеличава до 3072 байта. За MyISAM таблици ограничението за дължина на префикса е 1000 байта. Машината за съхранение на NDB изобщо не поддържа префикси.
Ако е активиран строг SQL режим и префиксът на индекса надвишава максималния размер на типа данни на колоната, CREATE INDEX изхвърля грешка. Ако строг SQL режим не е активиран, CREATE INDEX издава предупреждение. Ако се създаде УНИКАЛЕН ИНДЕКС, възниква грешка.
По принцип MySQL ви позволява да създавате само до 16 индекса в дадена таблица.
Ако използвате индекс на ПЪРВИЧЕН КЛЮЧ, можете да имате само един първичен ключ на таблица. ПЪЛЕН ТЕКСТ, УНИКАЛНИ ИНДЕКСИ и ИНДЕКСИ нямат това ограничение.
Ако използвате индекси FULLTEXT, имайте предвид, че те могат да се използват само за InnoDB или MyISAM машини за съхранение и за колони CHAR, VARCHAR или TEXT. Също така имайте предвид, че MySQL използва индекси FULLTEXT само когато се използват клаузи MATCH() AGAINST() и че всъщност можете да имате индекс и пълен текстов индекс в една и съща колона по едно и също време, ако желаете и че индексите FULLTEXT имат своите собствен набор от думи за спиране, всяка специфична за използваните машини за съхранение.
B-Tree индексите може да са полезни, ако използвате LIKE заявки, които започват със заместващ знак, но само в определени сценарии.

Познаването на тези ограничения на индекса би трябвало да се окаже полезно, ако се опитвате да разберете как работят индексите в MySQL. Това, което е още по-важно да разберете обаче, е фактът, че трябва да проверите дали вашите индекси действително се използват от MySQL. Засегнахме това накратко в първата част от тези серии („Как да изберем най-добрия индекс за използване?“), но не сме ви казали как да проверите дали вашите индекси действително се използват от MySQL. За да направите това, проверете използването им, като използвате EXPLAIN - когато EXPLAIN се използва заедно с обясним израз, MySQL показва информация от оптимизатора за плана за изпълнение на израза.

Съображения за ПЪРВИЧЕН КЛЮЧ

Някои от основните съображения, свързани с индексите на PRIMARY KEY в MySQL включват факта, че те се използват основно за уникално идентифициране на записи в таблица и често се използват с AUTO_INCREMENTing стойности, което означава, че могат да бъдат много полезни, ако създавате, да речем, полета за идентификация. Полетата на PRIMARY KEY трябва да съдържат уникални стойности и не могат да съдържат стойности NULL.

Съвпадение на префикс на колона

Индексите могат също да съвпадат с префикс на колона. Този подход към индексите може да бъде полезен, ако вашите колони са низови колони и смятате, че добавянето на индекс към цялата колона потенциално би изразходвало много дисково пространство. Вашите индекси могат да съвпадат с префикс на колона, както следва:

ALTER TABLE demo_table ADD INDEX index_name(column_name(length));

Горната заявка би добавила индекс index_name към колона с име column_name само за дефиниран префикс на колона. За да изберете добро количество дължина за индексиране, уверете се, че използването на префикса увеличава максимално уникалността на стойностите в колоната:намерете броя на редовете в таблицата и оценете различни дължини на префикса, докато постигнете желаната уникалност на редовете.

ПЪЛНОТЕКСТОВИ Индекси в MySQL

FULLTEXT индексите в MySQL са съвсем различен звяр. Те имат много ограничения, уникални за себе си (например, InnoDB има списък със стоп думи, състоящ се от 36 думи, докато MyISAM списъкът със стоп думи се състои от 143 думи), те също имат уникални режими на търсене. Някои от тях включват режим на естествен език (за да активирате такъв режим на търсене, изпълнете заявка за търсене с ПЪЛЕН ТЕКСТ без модификатори), можете също да разширите търсенето си (за да направите това, използвайте модификатора WITH QUERY EXPANSION - такъв режим на търсене изпълнява търсене два пъти, но когато търсенето се изпълнява за втори път, то включва няколко най-подходящи записа от първото търсене - често се използва, когато потребителят е намекнал, че знае нещо), за търсене с булеви оператори използвайте модификатора IN BOOLEAN MODE. Индексите FULLTEXT също ще се използват само ако заявката за търсене се състои от минимум три знака за InnoDB и минимум четири знака за MyISAM.

Използване на индекси на B-дърво с заместващи знаци

Индексите също се използват често, ако създавате нещо подобно на търсачките. За това често искате да търсите само част от стойност и да връщате резултатите - тук се намесват заместващите знаци. Една проста заявка, използваща заместващ знак, използва заявка LIKE и знака %, за да обозначи „всичко“ след текста. Например, заявка като тази ще търси резултати, започващи с думата „търсене“ и имащи нещо след нея:

SELECT * FROM … WHERE demo_column LIKE ‘search%’;

Заявка като тази ще търси резултати, започващи с каквото и да е, имаща думата „търсене“ и имаща нещо след нея:

SELECT * FROM … WHERE demo_column LIKE ‘%search%’;

Но ето една уловка - горната заявка няма да използва индекс. Защо? Тъй като има заместващ знак в началото на себе си и MySQL не може да разбере с какво колоната трябва да започне. Ето защо казахме, че индексите с заместващи знаци имат своето място, но само в конкретни сценарии – тоест такива, при които нямате заместващ знак в началото на заявката си за търсене.

Използване на ClusterControl за наблюдение на ефективността на заявките

Освен използването на EXPLAIN, можете също да използвате ClusterControl за наблюдение на ефективността на вашите заявки:ClusterControl предоставя набор от разширени функции за наблюдение и отчитане, които ви позволяват да следите ефективността на вашите екземпляри и заявки на базата данни . Например, щракнете върху клъстер и ще видите раздел „Монитор на заявки“. Кликнете върху него и ClusterControl ще ви позволи да наблюдавате състоянието на вашите заявки във вашата база данни:

Тази част от ClusterControl ви позволява да видите списък с най-добрите бавни и дълги изпълняват заявки, като същевременно ви позволяват да филтрирате през тях. Например, ако знаете, че неотдавна сте изпълнили заявка, състояща се от @@log_bin, можете просто да потърсите термина и ClusterControl ще върне списък с резултати:

Както вероятно забелязахте, можете също да филтрирате заявки по хостове, които използвате или по случаи, можете също да изберете да видите набор от редове, например 20, 100 или 200. ClusterControl също ще ви каже кога е видяна за последно заявката, какво е общото й време на изпълнение, колко реда е върнала, колко реда е прегледал и т.н. ClusterControl може да се окаже полезен, ако искате да наблюдавате как вашите индекси действително се използват от MySQL, MariaDB, MongoDB, PostgreSQL или TimescaleDB екземпляри.

Резюме

В тази публикация в блога преминахме през някои ограничения и предимства по отношение на индексите в MySQL и също така разгледахме как ClusterControl може да ви помогне да постигнете целите си за ефективност на базата данни. Ще имаме и трета част за индексите в MySQL, като се гмуркаме още по-дълбоко в тях, но за да завършим това, което разгледахме досега, имайте предвид, че индексите в MySQL със сигурност имат свое собствено място - за да се възползвате максимално от тях, знайте как взаимодействат с механизмите за съхранение, техните предимства и ограничения, как и кога да използвате определени типове индекси и да избирате разумно.