Forstå indekser i MySQL:Anden del

Dette blogindlæg er anden del af serien af ​​blogs om indekser i MySQL. I den første del af blogindlægsserien om MySQL-indekser har vi dækket ret mange ting, herunder hvad de er, hvad de gør, hvad deres typer er, hvordan man vælger optimale datatyper og MySQL-tegnsæt til indekser, som du bruger . Vi gennemgik fordele og ulemper ved at bruge indekser i MySQL; vi fortalte dig, hvordan du vælger det bedste indeks at bruge, hvordan du forbedrer forespørgselsydelsen og sikrer dig, at MySQL bruger dine indekser, hvor mange indekser skal du have. Vi gennemgik også nogle overvejelser i forbindelse med lagermotorer. Dette blogindlæg vil komme nærmere ind på noget af det indhold, vi har diskuteret i den første del af serien. Vi vil starte med sammenhængen mellem indekser og lagringsmotorer i MySQL.

Indekser og lagermotorer i MySQL

Som vi allerede har nævnt i et tidligere blogindlæg, kan der være nogle former for begrænsninger for indekser og andre ting, hvis du bruger visse storage-motorer i MySQL. Her er nogle af dem - vi vil nu definere, hvad nogle af dem er (nogle af dem blev dækket i første del af blog-serien, så hvis vi mangler noget, er det sandsynligvis derinde), så dække dem med en mere dybdegående analyse:

• I henhold til MySQL-dokumentationen er det maksimale antal indekser, den maksimale nøglelængde og den maksimale indekslængde defineret pr. lagermotor. Som vi allerede har nævnt i et tidligere blogindlæg, er det maksimale antal indekser pr. MyISAM- og InnoDB-tabeller 64, det maksimale antal kolonner pr. indeks i begge lagermotorer er 16, den maksimale nøglelængde for InnoDB er 3500 bytes og den maksimale nøglelængde for MyISAM er 1000 bytes.

• Du kan ikke bruge CREATE INDEX til at oprette en PRIMÆR NØGLE - brug ALTER TABLE i stedet.

• BLOB- og TEXT-kolonner kan kun indekseres for tabeller, der kører InnoDB-, MyISAM- og BLACKHOLE-lagringsmotorerne.

• Hvis du kun indekserer et præfiks for kolonnen, skal du huske på, at præfiksetstøtten og deres længde også er afhængig af lagermotorer. Et præfiks kan være op til 767 bytes langt for InnoDB-tabeller, der bruger REDUNDANT eller COMPACT rækkeformatet, men for DYNAMIC eller COMPRESSED rækkeformater øges præfikslængdegrænsen til 3072 bytes. For MyISAM-tabeller er præfikslængdegrænsen 1000 bytes. NDB-lagermotoren understøtter slet ikke præfikser.

• Hvis en streng SQL-tilstand er aktiveret, og indekspræfikset overskrider den maksimale kolonnedatatypestørrelse, kaster CREATE INDEX en fejl. Hvis en streng SQL-tilstand ikke er aktiveret, frembringer CREATE INDEX en advarsel. Hvis der oprettes et UNIKT INDEKS, opstår der en fejl.

• Generelt tillader MySQL dig kun at oprette op til 16 indekser på en given tabel.

• Hvis du bruger et PRIMÆR NØGLEindeks, kan du kun have én primærnøgle pr. tabel. FULLTEXT, UNIQUE INDEX'er og INDEX'er har ikke denne begrænsning.

•  Hvis du bruger FULLTEXT-indekser, skal du huske på, at de kun kan bruges til InnoDB- eller MyISAM-lagringsmotorer og for CHAR-, VARCHAR- eller TEXT-kolonner. Husk også, at MySQL kun bruger FULLTEXT-indekser, når der bruges MATCH() AGAINST()-sætninger, og at du faktisk kan have et indeks og et fuldtekstindeks på samme kolonne på samme tid, hvis du ønsker det, og at FULLTEXT-indekser har deres eget sæt af stopord, der hver især er specifikke for lagringsmotorer i brug.

• B-Tree-indekser kan være nyttige, hvis du bruger LIKE-forespørgsler, der begynder med et jokertegn, men kun i visse scenarier.

Kendskab til disse indeksbegrænsninger skulle vise sig at være nyttigt, hvis du forsøger at forstå, hvordan indekser i MySQL fungerer. Hvad der dog er endnu vigtigere at forstå, er det faktum, at du skal verificere, at dine indekser faktisk bruges af MySQL. Vi har berørt dette kort i den første del af denne serie ("Hvordan vælger du det bedste indeks at bruge?"), men vi har ikke fortalt dig, hvordan du verificerer, at dine indekser faktisk bruges af MySQL. For at gøre det skal du verificere deres brug ved at bruge EXPLAIN - når EXPLAIN bruges sammen med en erklæring, der kan forklares, viser MySQL information fra optimeringsværktøjet om udførelsesplanen for sætningen.

PRIMÆRE NØGLEovervejelser

Nogle af de grundlæggende overvejelser vedrørende PRIMÆRE NØGLEindekser i MySQL omfatter det faktum, at de primært bruges til entydigt at identificere poster i en tabel og ofte bruges med AUTO_INCREMENTing-værdier, hvilket betyder, at de kan være meget nyttige, hvis du opretter f.eks. ID-felter. PRIMÆRE NØGLE-felter skal indeholde unikke værdier, og de må ikke indeholde NULL-værdier.

Matchning af et kolonnepræfiks

Indekser kan også matche et kolonnepræfiks. Denne tilgang til indekser kan være nyttig, hvis dine kolonner er strengkolonner, og du tror, ​​at tilføjelse af et indeks på hele kolonnen potentielt ville forbruge meget diskplads. Dine indekser kan matche et kolonnepræfiks som sådan:

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

Ovenstående forespørgsel tilføjer kun et indeksindeksnavn på en kolonne med navnet kolonnenavn for et defineret kolonnepræfiks. For at vælge en god mængde længde, der skal indekseres, skal du sørge for, at din brug af præfikset maksimerer unikheden af ​​værdierne i kolonnen:find antallet af rækker i tabellen og vurder forskellige præfikslængder, indtil du opnår den ønskede unikke rækker.

FULLTEXT-indekser i MySQL

FULLTEXT-indekser i MySQL er et helt andet dyr. De har mange begrænsninger, der er unikke for dem selv (for eksempel har InnoDB en stopordsliste bestående af 36 ord, mens MyISAM stopordslisten består af 143 ord), de har også unikke søgetilstande. Nogle af dem inkluderer en naturlig sprogtilstand (for at aktivere en sådan søgetilstand, kør en FULLTEXT-søgeforespørgsel uden modifikatorer), du kan også udvide din søgning (for at gøre det skal du bruge WITH QUERY EXPANSION-modifikatoren - sådan en søgetilstand udfører søg to gange, men når søgningen kører for anden gang, inkluderer den et par mest relevante poster fra den første søgning - ofte brugt, når en bruger har underforstået viden om noget), for at søge med booleske operatorer, brug IN BOOLEAN MODE modifier. FULLTEXT-indekser vil også kun blive brugt, hvis søgeforespørgslen består af minimum tre tegn for InnoDB og minimum fire tegn for MyISAM.

Brug af B-Tree-indekser med jokertegn

Indekser bruges også ofte, hvis du bygger noget, der ligner søgemaskiner. Til det ønsker du ofte kun at søge efter en del af en værdi og returnere resultaterne - her træder jokertegn ind. En simpel forespørgsel, der bruger et jokertegn, bruger en LIKE-forespørgsel og %-tegnet til at angive "hvad som helst" efter teksten. For eksempel vil en forespørgsel som sådan søge efter resultater, der begynder med ordet "søg" og har alt efter det:

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

En forespørgsel som sådan ville søge efter resultater, der begynder med hvad som helst, med ordet "søg" og har alt efter det:

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

Men her er en catch - ovenstående forespørgsel vil ikke bruge et indeks. Hvorfor? Fordi den har et jokertegn i begyndelsen af ​​sig selv, og MySQL kan ikke finde ud af, hvad kolonnen skal begynde med. Det er derfor, vi sagde, at jokertegn har deres plads, men kun i specifikke scenarier - det vil sige sådanne scenarier, hvor du ikke har et jokertegn i begyndelsen af ​​din søgeforespørgsel.

Brug af ClusterControl til at overvåge ydelsen af ​​forespørgsler

Udover at bruge EXPLAIN, kan du også bruge ClusterControl til at overvåge ydeevnen af ​​dine forespørgsler:ClusterControl tilbyder et sæt avancerede overvågnings- og rapporteringsfunktioner, der lader dig holde styr på ydeevnen af ​​dine databaseforekomster og forespørgsler . Klik for eksempel på en klynge, og du vil se fanen "Forespørgselsovervågning". Klik på den, og ClusterControl vil lade dig observere status for dine forespørgsler i dine databaseforekomster:

Denne del af ClusterControl giver dig mulighed for at se en liste over de mest langsomme og lang- kører forespørgsler samtidig med, at du kan filtrere gennem dem. Hvis du for eksempel ved, at du for ikke længe siden kørte en forespørgsel, der bestod af @@log_bin, kan du blot søge efter udtrykket, og ClusterControl vil returnere en liste med resultater:

Som du sikkert har bemærket, kan du også filtrere forespørgsler efter værter, du bruger eller ved forekomster, kan du også vælge at se et sæt rækker, for eksempel 20, 100 eller 200. ClusterControl vil også fortælle dig, hvornår forespørgslen sidst blev set, hvad var dens samlede udførelsestid, hvor mange rækker den havde returneret, hvor mange rækker undersøgte den og så videre. ClusterControl kan vise sig at være medvirkende, hvis du vil observere, hvordan dine indekser faktisk bruges af MySQL-, MariaDB-, MongoDB-, PostgreSQL- eller TimescaleDB-forekomster.

Oversigt

I dette blogindlæg gennemgik vi nogle begrænsninger og fordele vedrørende indekser i MySQL, og vi har også dækket, hvordan ClusterControl kan hjælpe dig med at nå dine databasepræstationsmål. Vi vil også have en tredje del om indekser i MySQL, der dykker endnu dybere ned i dem, men for at konkludere, hvad vi har dækket indtil videre, skal du huske på, at indekser i MySQL bestemt har deres egen plads - for at få det bedste ud af dem, ved at hvordan de interagerer med lagermotorer, deres fordele og begrænsninger, hvordan og hvornår de skal bruge visse typer indekser og vælge klogt.