Teknologian jakaminen

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Sisällysluettelo

Hakemistosovellus

Mitä indeksejä MySQL:llä on?

Mitä eroa on tavallisella ja ainutlaatuisella indeksillä?

Klusteroidun indeksin ensisijaisen avainindeksin asettaminen Kysymys: Mitä tapahtuu, jos et aseta sitä?

Millaisia ​​kenttiä yleensä valitsemme indeksien rakentamiseen?

Onko enemmän indeksejä parempia?

Kuinka optimoida indeksi (Kattaa indeksin optimoinnin, estää indeksin epäonnistumisen, ensisijaisen avaimen lisäyksen, etuliiteindeksin optimoinnin)

Jos indeksi luodaan, käytetäänkö sitä kyselyssä (Indeksin epäonnistuminen, optimoija valitsee suoritussuunnitelman kustannusten perusteella)

Jos määritän varchar-tyyppisen päivämääräkentän ja yksi tiedoista on '20230922' ja jos tässä päivämääräkentässä on indeksi, niin jos kyselyni where-ehto on missä aika=20230922 ilman yksittäisiä lainausmerkkejä, indeksi vielä osuu?

Onko MySQL:n uusin versio ratkaissut indeksivirheitä (Funktion indeksi: funktion laskema arvo voidaan myös indeksoida, indeksin hyppyskannausmekanismi (vasen etuliite))

Mikä on vasemmanpuoleisin sovitusperiaate?

Mihin minun tulee kiinnittää huomiota yhteistä hakemistoa luotaessa (Aseta erottuvimmat äärivasemmalle, vasen vastaavuusperiaate, äläkä käytä indeksiä aluekyselyn jälkeen)

Vasemmanpuoleisin vastaavuusperiaate kyselyjärjestys

Mikä on indeksin painaminen? Lisätty MySQL5.6:een tietokyselyjen optimoimiseksi

Miten luodaan indeksi, jossa a>1 ja b=2 ja c <3?

(A,B,C) yhteisindeksi valitse * tbn:stä, jossa a= ja b in (?,?) ja c>?

Miten luodaan yhteinen indeksi, jossa a>100 ja b=100 ja c=123 järjestyksessä d?

valitse id, nimi XX:stä jossa ikä > 10 ja nimi kuten'xx%', siellä on yhteinen indeksi (nimi, ikä), puhutaanpa kyselyprosessista

---

Hakemistosovellus

MySQLMitä indeksejä siellä on?

Opin, että MySQL:llä onpääavainHakemisto, yksilöllinen indeksi, tavallinen indeksi, etuliiteindeksi,Unionin indeksiTämän tyyppiset indeksit.

Innodb-moottori edellyttää, että jokaisessa tietokantataulukossa on oltava apääavainindeksi，Indeksisarakkeen arvot eivät ole sallittujanolla-arvo。Esimerkiksi taulukon id-kenttä on ensisijainen avainindeksi

Ainutlaatuinen indeksi: Varmista tietosarakkeen jokaisen tietorivin yksilöllisyys, mutta salli nolla-arvot.

SittenKentille, joita kysytään usein, voimme luoda tälle kentälle normaalin indeksin.，Jos kenttiä on useita, voit harkita niiden luomistaUnionin indeksi,käyttääIndeksin kattavuusOminaisuudet parantavat kyselyn tehokkuutta.

Pitkälle tekstille, merkkijonolle ja muun tyyppisille kentille, kuten artikkelien otsikoille, tuotenimille jne., voimme indeksoida vain näiden kenttien etuliiteosan, eliLuo etuliiteindeksi vähentääksesi indeksin tallennustilaa.

Mitä eroa on tavallisella ja yksilöllisellä indeksillä Kummalla on parempi päivityskyky? 、

• Yksilöllinen indeksi voi olla hieman nopeampi, kun haetaan yksittäistä arvoa, koska se voi lopettaa haun löydettyään ensimmäisen vastaavuuden.

• Lisäys- ja päivitystoiminnoissa normaali indeksi voi olla hieman nopeampi, koska se ei vaadi ainutlaatuisuustarkistuksia.

1. Tavallisten indeksisarakkeiden arvot voidaan toistaa, mutta yksilöllisten indeksisarakkeiden arvojen on oltava yksilöllisiä Kun lisäämme toistuvan arvon yksilölliseen indeksiin, virheilmoitus johtuu ainutlaatuisuusrajoituksesta.

2. mielestäniTavallisen indeksin päivityssuorituskyky on parempi, koska kun tavallinen hakemisto päivitetään, jos päivitetty tietosivu ei oleMuisti Jos näin on, voit tallentaa päivitystoiminnon suoraan välimuistiin muutospuskuriin, jolloin päivitys suoritetaan loppuun. (ei vaadi yksilöllisyyden tarkistusta)

3. mutta,Ainutlaatuisella hakemistolla on oltava yksilölliset rajoitukset, jos päivitetty tietosivu ei oleMuistiJos näin on, sinun on luettava vastaava tietosivu levyltä muistiin selvittääksesi, onko kyseessä ristiriita.IOPääsy.

4. Koska tavalliset indeksit voivat käyttää muutospuskuriominaisuutta, tavallisten indeksien päivitys on nopeampaa kuin yksilöllisten indeksien.Vähentynyt satunnainen levykäyttö, joten päivityksen suorituskyky on parempi

klusteroitu indeksi/pääavainMiten indeksi asetetaan? Kysymys: Mitä tapahtuu, jos et aseta sitä?

Kun InnoDB luo klusteroidun indeksin, se valitsee eri sarakkeita indekseiksi eri skenaarioiden mukaan:

1. Jos ensisijainen avain on olemassa, sitä käytetään oletusarvoisesti klusteroidun indeksin indeksiavaimena.

2. Jos ensisijaista avainta ei ole, valitseEnsimmäinen ei sisällä NULL arvoAinoa sarake on asklusteroitu indeksiindeksi avain

3. Jos kumpaakaan yllä olevista ei ole, InnoDB luo automaattisesti implisiittisen automaattisesti kasvavan rivisarakkeen klusteroidun indeksin indeksiavaimeksi.

Millaisia ​​kenttiä yleensä valitsemme indeksien rakentamiseen?

Skenaariot, joissa indeksointia voidaan soveltaa:

1. Kentillä on ainutlaatuisuusrajoituksia, kuten tuotekoodi

2. Kentät, joita käytetään usein WHERE-kyselyehdoissa, joka voi parantaa koko taulukon kyselyn nopeutta Jos kyselyehto ei ole kenttä, voidaan muodostaa yhteinen indeksi

3. Kentät, joita käytetään usein GROUPBY:ssä ja ORDER BY:ssä, joten sinun ei tarvitse lajitella uudelleen haettaessa, koska kaikki B+-puun tietueet lajitellaan indeksin luomisen jälkeen.

Skenaariot eivät sovellu indeksointiin

1. Kenttiä ei käytetä WHERE-ehdoissa, GROUP BY, ORDER BY, indeksin arvo on pikapaikannus Jos kenttää ei voi sijoittaa, ei yleensä tarvitse luoda indeksiä, koska indeksi vie fyysistä tilaa.

2. Heikosti erottuva kentät , ei ole tarvetta luoda indeksiä, esimerkiksi sukupuolikentässä on vain miehet ja naiset. saada.Näissä tapauksissa on parempi olla indeksoimatta, koska MySQLYksi on vieläkyselyn optimoija, kun kyselyn optimoija havaitsee, että tietty arvo esiintyy suurella prosenttiosuudella taulukon tietoriveistä, se yleensä jättää indeksin huomioimatta ja suorittaaTäysi taulukon skannaus。

3. Usein päivitetyt kentätälä esimerkiksi indeksoi verkkokauppaprojektien käyttäjäsaldoa, koska indeksikenttiä muutetaan usein.ylläpitää B+puujärjestyksessä, silloin tarvitaan usein indeksien uudelleenrakentamista, ja tämä prosessi vaikuttaa tietokannan suorituskykyyn.

4. Järjestämättömien arvojen käyttöä ei suositella(kuten henkilökortti, UUID) indeksiksi, kun ensisijainen avain on epävarma, se aiheuttaa usein lehtien solmujen halkeilua ja levymuistin pirstoutumista.

• Tietotaulukko on pienempi: Kun taulukon datamäärä on pieni tai kun kysely edellyttää suuren osan taulukon tiedoista skannausta, tietokannan optimoija voi valita koko taulukon tarkistuksen indeksin käyttämisen sijaan. Tässä tapauksessa indeksin ylläpitokustannukset voivat olla suuremmat kuin suorituskyvyn lisäys.

Onko enemmän indeksejä parempia?

Ei, vaikka indeksit voivat parantaa kyselyn tehokkuutta, yhden indeksin lisääminen tarkoittaa, että luodaan uusi B+-puuindeksi, joka vie tallennustilaa varsinkin, kun taulukkotietojen määrä on erittäin suuri, indeksi vie enemmän tilaa.

Mitä enemmän indeksejä on, sitä enemmän tietokannan kirjoitusteho heikkenee, koska aina kun lisäät, poistat tai muokkaat taulukkoa, sinun on säilytettävä kunkin B+-puuindeksin järjestys.

Kuinka optimoida indeksi?kattava indeksiOptimoi ja ehkäise hakemistovirhe,pääavainInkrementaalinen etuliiteindeksin optimointi)

Olen käyttänyt näitä optimointimenetelmiä

1. Voimme luoda SQL:lle, joka tarvitsee tietoja useilta kentiltäUnionin indeksi, joten kyselymenetelmästä tuleekattava indeksi, välttäen taulukon taustan ja vähentäen suurta määrää I/O-toimintoja.

2. meidänpääavainIndeksit ovat edullisesti nousevia arvoja, koska hakemistomme tallentaa tiedot järjestyksessä, jos ensisijaisen avaimen arvo on satunnainen, sivun jakaminen voi aiheuttaa suuren määrän muistin katkelmia, joten hakemistorakenne ei ole kompakti vaikuttaa kyselyn tehokkuuteen.

3. me haluammeVältä hakemistovirheiden kirjoittamista SQL Lausekkeet, kuten älä suorita vasenta tai vasenta sumeaa hakua hakemistosarakkeille, eivät suorita laskutoimituksia, funktioita ja tyyppimuunnostoimintoja indekseille Jotta yhteisiä indeksejä voidaan käyttää oikein, sinun on noudatettava vasemmanpuoleisinta täsmäämisperiaatetta jne.Jos WHERE-lauseessa oleva ehtosarake ennen OR:ta on indeksisarake ja OR:n jälkeinen ehtosarake ei ole indeksisarake, indeksi epäonnistuu.

• Käytä ei ole yhtä suuri kuin (<>) tai NOT-operaattori: Nämä operaattorit yleensä mitätöivät indeksin, koska ne skannaavat koko taulukon.

• OR-operaattori: Jos OR-funktiota käytetään kyselyehdossa ja OR:n molemmilla puolilla on eri indeksejä, näitä indeksejä ei saa käyttää.

  • käyttää OR operaattori, josOR Molemmilla puolilla on erilaisia ​​indeksejä, eikä tietokantakone voi useimmissa tapauksissa käyttää useita indeksejä samanaikaisesti kyselyn optimointiin.Tämä onkoska OR Operaattorin tarvitsee vain täyttää kummankin puolen ehdot, mikä lisää kyselyn optimoinnin monimutkaisuutta.

1. Indeksointiin johonkin suureen merkkijonoon, voimme harkita käyttöäetuliiteindeksiVain hakemistosarakkeen etuliiteosa indeksoidaan hakemiston tallennustilan säästämiseksi ja kyselyn suorituskyvyn parantamiseksi.

2. Indeksi on parasta asettaa arvoon EI TYHJÄ : Jotta indeksiä voitaisiin hyödyntää paremmin, indeksisarakkeen arvoksi tulee asettaa NOT NULL -rajoitus. Syitä on kaksi:

   1. NULL-arvon esiintyminen indeksisarakkeissa tekee optimoijan indeksin valinnasta monimutkaisempaa, mikä vaikeuttaa toimintojen, kuten laskun, optimointia.

   2. NULL-arvo on merkityksetön arvo, mutta se vie fyysistä tilaa. Siinä on nolla-arvosarake.NULL:n tallentamiseen käytetään vähintään 1 tavu arvoluettelo

Jos hakemisto luodaan, käytetäänkö sitä kyselyssä (Indeksivirhe?optimoijaValitse toteutussuunnitelma kustannusten perusteella)

ei.

1. OpinVaikka kysely käyttää indeksiä, se ei välttämättä käytä indeksiä.

   1. Esimerkiksi: Kun kyselykäskymme suorittaa vasemman sumean vastaavuuden, lausekkeen laskennan, funktion ja implisiittisen tyypin muunnostoiminnot indeksikentässä, kyselykäsky ei voi mennä indeksin läpi ja kyselymenetelmästä tulee koko taulukon tarkistus.

   2. Ja käytämmeUnionin indeksiJos kyselyssä ei noudateta vasemmanpuoleisinta täsmäytysperiaatetta, tapahtuu myös indeksivirhe.。

2. Optimoija onValitse kyselymenetelmä kustannusnäkökohtien perusteella, käytettäessä toissijaista indeksiä kyselyyn, optimoija laskee taulukon palautuksen ja täyden taulukon skannauksen kustannukset. Jos taulukon palautuksen hinta on liian korkea, optimoija ei käytä indeksiä, vaan käyttää koko pöydän skannaus.

Jos määritän varchar-tyyppisen päivämääräkentän ja yksi tiedoista on '20230922' ja jos tässä päivämääräkentässä on indeksi, niin jos kyselyni where-ehto on missä aika=20230922 ilman yksittäisiä lainausmerkkejä, indeksi vielä osuu?

Ei osu indeksiin.

Koska mysql kohtaaMerkkijonojen ja numeroiden vertailutapahtuu milloinimplisiittinen tyyppimuunnos, tuleeMuunna merkkijonoobjekti numeroksi, tämä muunnosprosessi itse asiassa sisältäätoiminto . Mainitsemassasi kyselyssä päivämääräkenttä on merkkijono, joten kun implisiittinen tyyppimuunnos tapahtuu, sitä käytetään päivämääräindeksikenttään, jos indeksille suoritetaan funktiolaskenta, indeksi ei kelpaa.

Esimerkiksi kokonaislukutyyppisille hakemistosarakkeilleid Sarake, jonka arvo on tallennettu suoraan indeksiin ilman funktion laskentaa.Tämä tarkoittaa käyttöä kyselyssäidKun sovitetaan, se ei ole välttämätöntäidSuorita toiminnallisia laskelmia tai muunnoksia ja vertaa yksinkertaisesti kokonaislukuarvoja.

MySQLOnko viimeisin versio ratkaissut hakemistovirheitä (toimintoindeksi:funktion laskeminenJälkimmäinen arvo voidaan myös indeksoida ja indeksin ohitusskannausmekanismi (vasemmanpuoleisin etuliite)

Opin, että MySQL8.0 voi lisätä kenttiätoimintoindeksi, tämä uusi ominaisuus voi ratkaista indeksivirheen ongelman käytettäessä hakemiston toimintoja.

Toinen uusi ominaisuus onhakemiston ohitusskannaus, Ennen versiota 5.7 yhteisindeksiä käytettäessä, jos vasemmanpuoleisin täsmäytysperiaate ei täyty, hakemistovirhe tapahtuu kuitenkin sen jälkeen, kun hakemiston ohitusskannaus on otettu käyttöön versiossa 8.0, yhteisiä indeksejä voidaan edelleen käyttää, vaikka vasemmanpuoleisin täsmäysperiaate olisikin käytössä. ei noudateta.

Mikä on vasemmanpuoleisin sovitusperiaate?

Oletetaan, että on (a, b, c) yhteinen indeksi. Sen tallennusjärjestys on lajitella ensin a:n mukaan, sitten lajitella b:n mukaan, kun a on sama, ja sitten c:n mukaan, kun b on sama. Tästä ominaisuudesta johtuen yhteisiä indeksejä käytettäessä on käytössä vasemmanpuoleinen täsmäysperiaate. Erityiset säännöt ovat:

1. MySQL:n yhdistetty indeksi alkaaVasemmanpuoleisin hakemistosarake alkaa vastata kyselyn ehtoja ja vastaa sitten järjestyksessä vasemmalta oikealle. Jos kyselyehdot eivät käytä saraketta, kaikkia sarakkeen oikealla puolella olevia sarakkeita ei voida indeksoida.

2. Kun saraketta käytetään kyselytilassa,Tämän sarakkeen arvo sisältää kuitenkin aluekyselyn, ja aluekyselyn kenttiä voidaan käyttääUnionin indeksi, mutta yhteisindeksiä ei voi käyttää aluekyselykentän takana olevissa kentissä.

Siksi, kun käytämme yhteisiä indeksejä, meidän on noudatettava vasemmanpuoleisinta vastaavuusperiaatetta, muuten joitain indeksikenttiä ei ehkä indeksoida.

PerustaaUnionin indeksiOnko jotain, mihin meidän on kiinnitettävä huomiota (erillisimmät sijoitetaan äärivasemmalle, vasen vastaavuusperiaate, eikä indeksiä käytetä aluekyselyn jälkeen)

1. suurin osaAseta kentät erottuvamminUnionin indeksiäärivasemmalla, apuaParanna indeksin suodatustehoa, kentät, kuten UUID, sopivat paremmin indeksointiin tai sijoitukseen yhteisen indeksisarakkeen yläosassa.

2. Jos kenttä, jonka erottelu on vähäistä, sijoitetaan yhteisindeksin vasemmalle puolelle, kyselyn optimoija voi valita koko taulukon tarkistuksen indeksin käyttämisen sijaan.

3. Yhteysindeksin vasemmanpuoleisin täsmäytysperiaate, inKun kohtaat alueen kyselyn (kuten >, <), haku pysähtyy, eli aluekyselyn kentät voivat käyttää yhteisindeksiä, mutta aluekyselykentän takana olevat kentät eivät voi käyttää yhteisindeksiä.Kuitenkin neljän alueen kyselyn >=, <=, BETWEEN ja kuten etuliitehakujen kohdalla haku ei lopu.

   1. MySQL:ssä BETWEEN sisältää arvo1- ja arvo2-raja-arvot, jotka ovat samanlaisia ​​kuin >= ja =<.

   2. Viitelinkki https://zhuanlan.zhihu.com/p/573138586

Vasemmanpuoleisin vastaavuusperiaate kyselyjärjestys

select * from T where c=1 and a=2 and b=3;

abc voidaan indeksoida, koska Kyselyn ehtokenttien järjestys ei vaikuta, MySQL-optimoija auttaa meitä säätämään kenttien kyselyjärjestystä, joten se noudattaa myös vasemmanpuoleisinta vastaavuusperiaatetta.

indeksin allatyöntää Mikä se on? Lisätty MySQL5.6:een tietokyselyjen optimoimiseksi

Indeksin painaminen voi pienentäätoissijainen indeksiTaulukon palautustoiminto kyselyn aikana parantaa kyselyn tehokkuutta, koska se tekee niin Palvelinkerros on vastuussa joistakin asioista, joita tallennuskonekerros käsittelee.Meni käsittelemään sitä.

• Kun painetaan optimointia käyttämättä indeksiehtoja, tallennuskone noutaa tiedot indeksin kautta ja palauttaa ne sitten MySQL Serveriin.MySQL-palvelin Tee arviot suodattimen olosuhteista.

• Jos indeksoiduille sarakkeille on olemassa tiettyjä arviointiehtoja, MySQL Server työntää tämän osan arviointiehdoista tallennuskoneeseen, ja sitten tallennuskone arvioi, täyttääkö indeksi ehtoja, jotka ovat indeksoidut. MySQL-palvelin vain, kun indeksi täyttää ehdot, tiedot haetaan ja palautetaan MySQL-palvelimelle.

Hakemiston tilan pushdown-optimointi voi vähentää sitä, kuinka monta kertaa tallennuskone tekee kyselyitä taustalla olevasta taulukosta, ja voi myös vähentää MySQL Kuinka monta kertaa palvelin vastaanotti tietoja tallennuskoneesta.

select * from t_user where age > 20 and reward = 100000;

Miten luodaan indeksi, jossa a>1 ja b=2 ja c <3?

1. Luo (abc), (acb), (ab), (ac) yhteisindeksi, vain a voi indeksi

2. Luo (cab), (cba), (ca), (cb) yhteiset indeksit, vain c voi indeksoida

3. Luo (ba) yhteinen indeksi, sekä b että a voidaan indeksoida

4. Luo (bc) yhteisindeksi, sekä b että c voidaan indeksoida

5. luo (bac) Unionin indeksi, b ja a voidaan molemmat indeksoida, mutta ne ovat hitaampia kuin (ba) yhteisindeksillä on vielä yksi etu, c-kentässä voiindeksi alaspäin, vähentää taulukon palautusten määrää;

6. luoda(bca) Unionin indeksi, sekä b että c voidaan indeksoida, mutta sillä on yksi etu enemmän kuin (bc) yhteisindeksi, a-kenttä voiindeksi alaspäin, vähentää taulukon palautusten määrää;

(A,B,C) yhteisindeksi select * from tbn where a=? and b in (?,?) and c>? Indeksoidaanko se?

Tämä kysely käyttää yhteisindeksiä (A,B,C), koska ehto perustuu indeksisarakkeeseen A、B、C Tilaus tulee, mikä on ihanteellinen käyttöskenaario.

1. varten A=?: Tämä ehto on tarkka vastaavuus. MySQL käyttää indeksiä paikantaakseen ehdon. A=? ennätys.

2. varten B IN (?, ?): Tämä ehto määrittää B Sarake voi ottaa kaksi mahdollista arvoa. MySQL käyttää hakemistoa löytääkseen kaikki osumatA=? jaB Sarake on tietue, jossa on jompikumpi näistä kahdesta arvosta.

3. varten C>? : Tämä ehto on aluekysely.perustuu joA jaB Suodattimen perusteella MySQL jatkaa indeksin käyttöä etsimiseenC Tietueet, joiden sarakearvot ovat määritettyä arvoa suuremmat.

missä a>100 ja b=100 ja c=123 järjestys d:n mukaan miten luodaanUnionin indeksi?

mielestäniPerustaa bcda järjestyksessäUnionin indeksiParemmin, tällä hetkellä sekä b- että c-kentät voidaan indeksoida, jad voi käyttää hakemistojärjestystä välttääkseen tiedostojen lajittelun (ylimääräinen lajittelu), vaikka viimeistä kenttää ei voida indeksoida (a on epäkunnossa), se voidaan työntää alas indeksin avulla taulukon palautusten määrän vähentämiseksi.

valitse id , nimi XX, jossa ikä > 10 ja nimi kuten'xx%'，有Unionin indeksi(nimi, ikä), puhu kyselyprosessista

Yhteisindeksin järjestys on ensin nimi, sitten ikä. Rakenteellisesti se lajitellaan ensin nimen mukaan ja sitten iän mukaan, jos nimet ovat yhtä suuret.Siksi optimoijan on täsmättävä nimi ensin Nimi on tällä hetkellä oikea sumea kysely, eikä hakemistovirheitä tapahdu, joten tämä SQL voi käyttää yhteistä indeksointia.

Tarkemmin sanottuna vain nimi voidaan indeksoidaNimioikean sumean kyselyn jälkeen ikäkentän arvot eivät ole järjestyksessä, joten ikää ei voi indeksoida, mutta ikää voidaan indeksoida.indeksi alaspäin。

Viimeksi kysytyt kentät ovat id ja name Nämä kaksi kenttää löytyvät yhteishakemistosta, joten taulukkoa ei tarvitse palauttaa.

Nimeä oikea sumea kysely on aluekysely, eikä seuraavia kenttiä voida indeksoida