Förstå index i MySQL:Del två

Det här blogginlägget är den andra delen av serien med bloggar om index i MySQL. I den första delen av blogginläggsserien om MySQL-index har vi tagit upp ganska många saker, inklusive vad de är, vad de gör, vilka typer de är, hur man väljer optimala datatyper och MySQL-teckenuppsättningar för index som du använder . Vi gick igenom fördelarna och nackdelarna med att använda index i MySQL; vi berättade för dig hur du väljer det bästa indexet att använda, hur du förbättrar frågeprestanda och ser till att MySQL använder dina index, hur många index ska du ha. Vi gick också igenom några överväganden relaterade till lagringsmotorer. Det här blogginlägget kommer att gå in mer i detalj på en del av innehållet som vi har diskuterat i den första delen av serien. Vi börjar med korrelationen mellan index och lagringsmotorer i MySQL.

Index och lagringsmotorer i MySQL

Som vi redan har nämnt i ett tidigare blogginlägg kan det finnas vissa typer av begränsningar för index och andra saker om du använder vissa lagringsmotorer i MySQL. Här är några av dem - vi kommer nu att definiera vad några av dem är (några av dem behandlades i den första delen av bloggserien så om vi saknar något finns det förmodligen där), täck dem sedan med en mer djupgående analys:

I enlighet med MySQL-dokumentationen är det maximala antalet index, den maximala nyckellängden och den maximala indexlängden definieras per lagringsmotor. Som vi redan har nämnt i ett tidigare blogginlägg är det maximala antalet index per MyISAM- och InnoDB-tabeller 64, det maximala antalet kolumner per index i båda lagringsmotorerna är 16, den maximala nyckellängden för InnoDB är 3500 byte och den maximala nyckellängden för MyISAM är 1000 byte.
Du kan inte använda CREATE INDEX för att skapa en PRIMÄRNYCKEL – använd ALTER TABLE istället.
BLOB- och TEXT-kolumner kan endast indexeras för tabeller som kör lagringsmotorerna InnoDB, MyISAM och BLACKHOLE.
Om du bara indexerar ett prefix för kolumnen, tänk på att prefixstödet och deras längd också är beroende av lagringsmotorer. Ett prefix kan vara upp till 767 byte långt för InnoDB-tabeller som använder radformatet REDUNDANT eller COMPACT, men för DYNAMIC eller COMPRESSED radformat ökas prefixlängden till 3072 byte. För MyISAM-tabeller är prefixlängdgränsen 1000 byte. NDB-lagringsmotorn stöder inte prefix alls.
Om ett strikt SQL-läge är aktiverat och indexprefixet överskrider den maximala kolumndatatypens storlek, kastar CREATE INDEX ett fel. Om ett strikt SQL-läge inte är aktiverat, ger CREATE INDEX en varning. Om ett UNIKT INDEX skapas, uppstår ett fel.
I allmänhet tillåter MySQL dig bara att skapa upp till 16 index på en given tabell.
Om du använder ett PRIMÄRNYCKELindex kan du bara ha en primärnyckel per tabell. FULLTEXT, UNIKA INDEX och INDEX har inte denna begränsning.
Om du använder FULLTEXT-index, kom ihåg att de endast kan användas för InnoDB- eller MyISAM-lagringsmotorer och för kolumner CHAR, VARCHAR eller TEXT. Tänk också på att MySQL endast använder FULLTEXT-index när MATCH() AGAINST()-satser används och att du faktiskt kan ha ett index och ett fulltextindex på samma kolumn samtidigt om du så önskar och att FULLTEXT-index har sina egen uppsättning stoppord vart och ett specifikt för lagringsmotorer som används.
B-Tree-index kan vara användbara om du använder LIKE-frågor som börjar med ett jokertecken, men bara i vissa scenarier.

Att känna till dessa indexbegränsningar borde visa sig vara användbart om du försöker förstå hur index i MySQL fungerar. Vad som är ännu viktigare att förstå är det faktum att du måste verifiera att dina index faktiskt används av MySQL. Vi har berört detta kort i den första delen av dessa serier ("Hur man väljer det bästa indexet att använda?"), men vi har inte berättat för dig hur du verifierar att dina index faktiskt används av MySQL. För att göra det, verifiera deras användning genom att använda EXPLAIN - när EXPLAIN används tillsammans med en förklarande sats visar MySQL information från optimeraren om exekveringsplanen för satsen.

PRIMÄRA NYCKELöverväganden

Några av de grundläggande övervägandena relaterade till PRIMÄRKEY-index i MySQL inkluderar det faktum att de främst används för att unikt identifiera poster i en tabell och ofta används med AUTO_INCREMENTing-värden, vilket innebär att de kan vara mycket användbara om du skapar t.ex. ID-fält. PRIMARY KEY-fält måste innehålla unika värden och de får inte innehålla NULL-värden.

Matcha ett kolumnprefix

Index kan också matcha ett kolumnprefix. Det här tillvägagångssättet för index kan vara användbart om dina kolumner är strängkolumner och du tror att om du lägger till ett index på hela kolumnen skulle det potentiellt förbruka mycket diskutrymme. Dina index kan matcha ett kolumnprefix så här:

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

Frågan ovan skulle lägga till ett index index_name på en kolumn med namnet column_name endast för ett definierat kolumnprefix. För att välja en bra mängd längd att indexera, se till att din användning av prefixet maximerar unikheten för värdena i kolumnen:hitta antalet rader i tabellen och utvärdera olika prefixlängder tills du uppnår önskad unikhet av rader.

FULLTEXT-index i MySQL

FULLTEXT-index i MySQL är ett helt annat odjur. De har många begränsningar som är unika för dem själva (till exempel, InnoDB har en stoppordslista som består av 36 ord medan MyISAM stoppordslistan består av 143 ord), de har också unika söklägen. Vissa av dem inkluderar ett naturligt språkläge (för att aktivera ett sådant sökläge, kör en FULLTEXT sökfråga utan modifierare), du kan också utöka din sökning (för att göra det, använd WITH QUERY EXPANSION modifieraren - ett sådant sökläge utför sök två gånger, men när sökningen körs för andra gången innehåller den några mest relevanta poster från den första sökningen - används ofta när en användare har underförstått kunskap om något), för att söka med booleska operatorer använd modifieraren IN BOOLEAN MODE. FULLTEXT-index kommer också endast att användas om sökfrågan består av minst tre tecken för InnoDB och minst fyra tecken för MyISAM.

Använda B-Tree-index med jokertecken

Index används också ofta om du bygger något som liknar sökmotorer. För det vill du ofta bara söka efter en del av ett värde och returnera resultatet - det är här som jokertecken kommer in. En enkel fråga med ett jokertecken använder en LIKE-fråga och %-tecknet för att beteckna "vad som helst" efter texten. Till exempel skulle en fråga som den här söka efter resultat som börjar med ordet "sök" och har något efter det:

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

En fråga som den här skulle söka efter resultat som börjar med vad som helst, med ordet "sök" och med något efter det:

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

Men här är en hake - frågan ovan kommer inte att använda ett index. Varför? Eftersom den har ett jokertecken i början av sig själv och MySQL kan inte lista ut vad kolumnen behöver till att börja med. Det är därför vi sa att jokertecken har sin plats, men bara i specifika scenarier - det vill säga sådana scenarier där du inte har ett jokertecken i början av din sökfråga.

Använda ClusterControl för att övervaka prestanda för frågor

Förutom att använda EXPLAIN kan du också använda ClusterControl för att övervaka prestandan för dina frågor:ClusterControl tillhandahåller en uppsättning avancerade övervaknings- och rapporteringsfunktioner som låter dig hålla reda på prestandan för dina databasinstanser och frågor . Klicka till exempel på ett kluster och du kommer att se fliken "Frågeövervakare". Klicka på den och ClusterControl låter dig observera statusen för dina frågor i dina databasinstanser:

Den här delen av ClusterControl låter dig se en lista över de bästa långsamma och långa kör frågor samtidigt som du kan filtrera igenom dem. Om du till exempel vet att du för inte så länge sedan körde en fråga som bestod av @@log_bin, kan du helt enkelt söka efter termen och ClusterControl returnerar en lista med resultat:

Som du säkert har märkt kan du också filtrera frågor efter värdar som du använder eller genom tillfällen kan du också välja att se en uppsättning rader, till exempel 20, 100 eller 200. ClusterControl kommer också att berätta när frågan senast sågs, vad var dess totala körningstid, hur många rader den hade returnerat, hur många rader undersökte den och så vidare. ClusterControl kan visa sig vara avgörande om du vill observera hur dina index faktiskt används av MySQL, MariaDB, MongoDB, PostgreSQL eller TimescaleDB-instanser.

Sammanfattning

I det här blogginlägget gick vi igenom några begränsningar och fördelar gällande index i MySQL och vi har också täckt hur ClusterControl kan hjälpa dig att uppnå dina databasprestandamål. Vi kommer också att ha en tredje del om index i MySQL som dyker ännu djupare in i dem, men för att avsluta vad vi hittills har täckt, kom ihåg att index i MySQL verkligen har sin egen plats - för att göra det bästa av dem, vet du hur de interagerar med lagringsmotorer, deras fördelar och begränsningar, hur och när man använder vissa typer av index och väljer klokt.