Indexen in MySQL begrijpen:deel twee

Deze blogpost is het tweede deel van de serie blogs over indexen in MySQL. In het eerste deel van de serie blogposts over MySQL-indexen hebben we heel wat dingen behandeld, waaronder wat ze zijn, wat ze doen, wat hun typen zijn, hoe optimale gegevenstypen te kiezen en MySQL-tekensets voor indexen die je gebruikt . We hebben de voor- en nadelen doorgenomen van het gebruik van indexen in MySQL; we hebben u verteld hoe u de beste index kunt kiezen om te gebruiken, hoe u de queryprestaties kunt verbeteren en ervoor kunt zorgen dat MySQL uw indexen gebruikt, hoeveel indexen u moet hebben. We hebben ook enkele overwegingen met betrekking tot storage-engines doorgenomen. Deze blogpost gaat dieper in op een deel van de inhoud die we in het eerste deel van de serie hebben besproken. We beginnen met de correlatie tussen indexen en opslagengines in MySQL.

Indexen en opslagengines in MySQL

Zoals we al in een eerdere blogpost hebben vermeld, kunnen er bepaalde beperkingen zijn voor indexen en andere zaken als u bepaalde opslagengines in MySQL gebruikt. Hier zijn er enkele - we zullen nu definiëren wat sommige van hen zijn (sommige werden behandeld in het eerste deel van de blogreeks, dus als we iets missen, staat het daar waarschijnlijk in), en bedek ze dan met een meer diepgaande analyse:

• Volgens de MySQL-documentatie is het maximale aantal indexen, de maximale sleutellengte en de maximale indexlengte gedefinieerd per opslagmotor. Zoals we in een eerdere blogpost al vermeldden, is het maximale aantal indexen per MyISAM- en InnoDB-tabellen 64, het maximale aantal kolommen per index in beide storage-engines is 16, de maximale sleutellengte voor InnoDB is 3500 bytes en het maximale sleutellengte voor MyISAM is 1000 bytes.

• U kunt CREATE INDEX niet gebruiken om een ​​PRIMAIRE SLEUTEL te maken - gebruik in plaats daarvan ALTER TABLE.

• BLOB- en TEXT-kolommen kunnen alleen worden geïndexeerd voor tabellen met de InnoDB-, MyISAM- en BLACKHOLE-opslagengines.

• Als u alleen een prefix van de kolom indexeert, houd er dan rekening mee dat de prefixondersteuning en hun lengte ook afhankelijk van opslagmotoren. Een prefix kan tot 767 bytes lang zijn voor InnoDB-tabellen die de ROODUNDANT- of COMPACT-rijindeling gebruiken, maar voor DYNAMIC of COMPRESSED-rijindelingen wordt de limiet voor de lengte van de prefix verhoogd tot 3072 bytes. Voor MyISAM-tabellen is de limiet voor de lengte van het voorvoegsel 1000 bytes. De NDB-opslagengine ondersteunt helemaal geen voorvoegsels.

• Als een strikte SQL-modus is ingeschakeld en het indexvoorvoegsel de maximale grootte van het kolomgegevenstype overschrijdt, genereert CREATE INDEX een foutmelding. Als een strikte SQL-modus niet is ingeschakeld, geeft CREATE INDEX een waarschuwing. Als er een UNIEKE INDEX wordt gemaakt, treedt er een fout op.

• Over het algemeen kunt u met MySQL maximaal 16 indexen maken voor een bepaalde tabel.

• Als u een PRIMARY KEY-index gebruikt, kunt u slechts één primaire sleutel per tabel hebben. FULLTEXT, UNIEKE INDEX's en INDEX's hebben deze beperking niet.

•  Als u FULLTEXT-indexen gebruikt, moet u er rekening mee houden dat deze alleen kunnen worden gebruikt voor InnoDB- of MyISAM-opslagengines en voor CHAR-, VARCHAR- of TEXT-kolommen. Houd er ook rekening mee dat MySQL alleen FULLTEXT-indexen gebruikt wanneer MATCH() AGAINST()-clausules worden gebruikt en dat u desgewenst tegelijkertijd een index en een fulltext-index op dezelfde kolom kunt hebben en dat FULLTEXT-indexen hun eigen set stopwoorden die elk specifiek zijn voor gebruikte opslagengines.

• B-Tree-indexen kunnen handig zijn als u LIKE-query's gebruikt die met een jokerteken beginnen, maar alleen in bepaalde scenario's.

Het kennen van deze indexbeperkingen zou nuttig moeten zijn als u probeert te begrijpen hoe indexen in MySQL werken. Wat nog belangrijker is om te begrijpen, is het feit dat u moet verifiëren dat uw indexen daadwerkelijk door MySQL worden gebruikt. We hebben dit kort besproken in het eerste deel van deze serie (“Hoe kies je de beste index om te gebruiken?”), maar we hebben je niet verteld hoe je kunt controleren of je indexen daadwerkelijk door MySQL worden gebruikt. Om dat te doen, moet u hun gebruik verifiëren met EXPLAIN - wanneer EXPLAIN wordt gebruikt samen met een verklaarbare instructie, geeft MySQL informatie weer van de optimizer over het uitvoeringsplan van de instructie.

PRIMAIRE SLEUTEL Overwegingen

Sommige van de basisoverwegingen met betrekking tot PRIMARY KEY-indexen in MySQL zijn onder meer het feit dat ze voornamelijk worden gebruikt om records in een tabel uniek te identificeren en vaak worden gebruikt met AUTO_INCREMENTing-waarden, wat betekent dat ze erg handig kunnen zijn als u maakt bijvoorbeeld ID-velden. PRIMARY KEY-velden moeten unieke waarden bevatten en mogen geen NULL-waarden bevatten.

Overeenkomen met een kolomvoorvoegsel

Indexen kunnen ook overeenkomen met een kolomprefix. Deze benadering van indexen kan handig zijn als uw kolommen tekenreekskolommen zijn en u denkt dat het toevoegen van een index aan de hele kolom mogelijk veel schijfruimte zou verbruiken. Uw indexen kunnen als volgt overeenkomen met een kolomvoorvoegsel:

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

De bovenstaande query zou een index indexnaam toevoegen aan een kolom met de naam kolomnaam alleen voor een gedefinieerd kolomvoorvoegsel. Om een ​​goede lengte te kiezen om te indexeren, moet u ervoor zorgen dat uw gebruik van het voorvoegsel de uniciteit van de waarden in de kolom maximaliseert:zoek het aantal rijen in de tabel en evalueer de verschillende lengtes van het voorvoegsel totdat u de gewenste uniciteit van rijen bereikt.

FULLTEXT-indexen in MySQL

FULLTEXT-indexen in MySQL zijn een heel ander beest. Ze hebben veel beperkingen die uniek zijn voor zichzelf (innoDB heeft bijvoorbeeld een stopwoordenlijst die uit 36 ​​woorden bestaat, terwijl de MyISAM-stopwoordenlijst uit 143 woorden bestaat), ze hebben ook unieke zoekmodi. Sommigen van hen bevatten een natuurlijke taalmodus (om een ​​dergelijke zoekmodus te activeren, voer een FULLTEXT-zoekopdracht uit zonder modifiers), u kunt ook uw zoekopdracht uitbreiden (gebruik hiervoor de WITH QUERY EXPANSION-modifier - een dergelijke zoekmodus voert de zoek tweemaal, maar wanneer de zoekopdracht voor de tweede keer wordt uitgevoerd, bevat deze een paar meest relevante records van de eerste zoekopdracht - vaak gebruikt wanneer een gebruiker impliciete kennis van iets heeft). Gebruik de IN BOOLEAN MODE-modifier om te zoeken met booleaanse operators. FULLTEXT-indexen worden ook alleen gebruikt als de zoekopdracht voor InnoDB uit minimaal drie tekens en voor MyISAM uit minimaal vier tekens bestaat.

B-Tree-indexen gebruiken met jokertekens

Indexen worden ook vaak gebruikt als u iets bouwt dat lijkt op zoekmachines. Daarvoor wil je vaak alleen naar een deel van een waarde zoeken en de resultaten retourneren - hier komen jokertekens in beeld. Een eenvoudige zoekopdracht met een jokerteken gebruikt een LIKE-query en het %-teken om "alles" na de tekst aan te duiden. Een zoekopdracht als 'zo' zou bijvoorbeeld zoeken naar resultaten die beginnen met het woord 'zoeken' en iets erna hebben:

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

Een zoekopdracht als deze zou zoeken naar resultaten die met alles beginnen, met het woord 'zoeken' en alles erna:

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

Maar hier is een addertje onder het gras - de bovenstaande zoekopdracht gebruikt geen index. Waarom? Omdat het een jokerteken aan het begin van zichzelf heeft en MySQL niet kan achterhalen waar de kolom mee moet beginnen. Daarom hebben we gezegd dat wildcardindexen hun plaats hebben, maar alleen in specifieke scenario's - dat wil zeggen, scenario's waarin u geen wildcard aan het begin van uw zoekopdracht heeft.

ClusterControl gebruiken om de prestaties van query's te controleren

Naast het gebruik van EXPLAIN, kunt u ClusterControl ook gebruiken om de prestaties van uw query's te controleren:ClusterControl biedt een reeks geavanceerde bewakings- en rapportagefuncties waarmee u de prestaties van uw database-instanties en query's kunt bijhouden . Klik bijvoorbeeld op een cluster en u ziet een tabblad "Query Monitor". Klik erop en ClusterControl laat u de status van uw zoekopdrachten in uw database-instanties zien:

In dit deel van ClusterControl kunt u een lijst met langzame en lang- query's uitvoeren terwijl u er ook doorheen kunt filteren. Als u bijvoorbeeld weet dat u niet lang geleden een zoekopdracht heeft uitgevoerd die bestond uit @@log_bin, kunt u eenvoudig naar de term zoeken en ClusterControl retourneert een lijst met resultaten:

Zoals je waarschijnlijk hebt opgemerkt, kun je zoekopdrachten ook filteren op hosts die je gebruikt of per voorkomen, kunt u er ook voor kiezen om een ​​reeks rijen te zien, bijvoorbeeld 20, 100 of 200. ClusterControl zal u ook vertellen wanneer de query voor het laatst is gezien, wat de totale uitvoeringstijd was, hoeveel rijen deze had geretourneerd, hoeveel rijen heeft het onderzocht enzovoort. ClusterControl kan van pas komen als u wilt zien hoe uw indexen daadwerkelijk worden gebruikt door MySQL-, MariaDB-, MongoDB-, PostgreSQL- of TimescaleDB-instanties.

Samenvatting

In deze blogpost hebben we enkele beperkingen en voordelen met betrekking tot indexen in MySQL doorgenomen en hebben we ook besproken hoe ClusterControl u kan helpen uw databaseprestatiedoelen te bereiken. We zullen ook een derde deel hebben over indexen in MySQL die er nog dieper in duiken, maar om af te sluiten wat we tot nu toe hebben behandeld, houd er rekening mee dat indexen in MySQL zeker hun eigen plaats hebben - om er het beste van te maken, weet hoe ze omgaan met opslagengines, hun voordelen en beperkingen, hoe en wanneer bepaalde soorten indexen te gebruiken en verstandig te kiezen.