2024-07-12
한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina
Palvelinkerroksen vaiheet SQL:n suorittamiseksi peräkkäin ovat:
Asiakaspyyntö -> Liitin (tarkista käyttäjän henkilöllisyys ja myönnä käyttöoikeudet) Kyselyvälimuisti (palauta suoraan, jos välimuisti on olemassa, suorita seuraavat toiminnot, jos ei) Analyzer (suorita SQL:n leksikaalista analyysiä ja syntaksianalyysiä) Optimoija (suorita pääasiassa SQL-optimointimenetelmää parhaan valitsemiseksi suoritussuunnitelma) Suoritin (suorittaessaan se tarkistaa ensin, onko käyttäjällä suorituslupa, ja käyttää sitten tämän moottorin tarjoamaa käyttöliittymää) -> Siirry moottorikerrokseen saadaksesi tietojen palautuksen (jos kyselyvälimuisti on päällä, se tulee välimuistiin kyselyn tulokset)
Puskurivarasto on tärkeä osa InnoDB-tallennusmoottoria MySQL-tietokannassa. Sitä käytetään pääasiassa taulukkotietojen välimuistiin ja indeksointiin, joka vähentää levyn I/O-toimintoja ja parantaa tietokannan käsittelyn tehokkuutta. Seuraavassa on yksityiskohtainen analyysi puskurivarannosta:
määritelmä: Puskurivarasto on InnoDB-tallennuskoneen muistialue, jota käytetään tietosivujen ja hakemistosivujen välimuistiin levylle vähentämään suoraa pääsyä levyyn.
vaikutus: Paranna tietojen käyttönopeutta ja pienennä levyn I/O-kustannuksia välimuistimekanismin avulla.
sävellys : Puskurivarasto koostuu välimuistissa olevista tietosivuista (Page) ja vastaavista ohjauslohkoista. Ohjauslohko tallentaa välimuistisivun metatietotiedot, kuten taulukkotilan, johon se kuuluu, tietosivun numeron, välimuistisivun osoitteen puskurivarastossa jne.
oletuskoko: MySQL:n puskurivarannon oletuskoko on yleensä 128 Mt (mutta huomaa, että MySQL:n eri versiot tai erilaiset kokoonpanot voivat aiheuttaa oletuskoon erilaisen).
Konfigurointiparametrit:kulkeainnodb_buffer_pool_sizeParametrit voivat määrittää puskurivarannon koon. Yleensä suositellaan asettamaan se 60–80 %:iin järjestelmämuistista.
muistin varaus: Puskurivarasto on jatkuva muistitila Kun MySQL on käynnissä jonkin aikaa, tässä muistitilassa on sekä vapaita välimuistisivuja että käytettyjä välimuistisivuja.
tyyppi
: Puskurivaraston tietosivut voidaan jakaa kolmeen tyyppiin niiden tilan mukaan: Vapaa sivu, Puhdas sivu ja Likainen sivu.
Ilmaiset sivut: välimuistisivut, joita ei käytetä.
Puhdista sivu: Välimuistisivu, jota on käytetty, mutta tietoja ei ole muokattu.
Likainen sivu: Välimuistisivu, jota on käytetty ja tietoja on muokattu, ja sen tiedot ovat ristiriidassa levyllä olevien tietojen kanssa.
hallita
: InnoDB hallitsee näitä välimuistisivuja kolmen linkitetyn luettelorakenteen kautta:
Ilmainen linkitetty luettelo: hallitsee ilmaisia sivuja ja tallentaa ilmaisten välimuistisivujen ohjauslohkotiedot.
LRU-linkitetty luettelo: hallitsee puhtaita ja likaisia sivuja, käyttää parannettua LRU-algoritmia ja jaetaan nuoriin ja vanhoihin alueisiin välimuistin osumasuhteen optimoimiseksi.
Tyhjennä linkitetty luettelo: hallitsee likaisia sivuja, jotka on huuhdeltava levylle, lajiteltuna muokkausajan mukaan.
pääsy tietoihin : Kun tietosivua on käytettävä, InnoDB tarkistaa ensin, onko sivu jo puskurivarastossa. Jos se on jo olemassa, sivua käytetään suoraan, jos sitä ei ole olemassa, sivu luetaan levyltä puskurivarastoon ja vastaava linkitetty luettelo päivitetään.
Tietojen päivitys: Kun tietosivua muokataan, sivu merkitään likaiseksi sivuksi ja se voidaan lisätä Tyhjennä-linkkiluetteloon odottamaan, että taustasäie huuhtelee sen levylle.
välimuistin häätö: Kun puskurivarasto ei riitä, vähiten käytetty välimuistisivu poistetaan LRU-algoritmin mukaan.
Aseta koko sopivaksi: Järkevät asetukset perustuvat järjestelmän muistiin ja tietokannan latausolosuhteisiininnodb_buffer_pool_sizeparametri.
Tarkkaile ja säädä: Seuraa säännöllisesti puskurivarannon käyttö- ja suorituskykyindikaattoreita ja tee tarvittavat säädöt.
Vältä täyden pöydän skannausta: Täysi taulukon tarkistus aiheuttaa suuren määrän tietosivuja lataamisen puskurivarastoon, mikä vähentää välimuistin osumaprosenttia.
Yhteenvetona voidaan todeta, että puskurivarasto on yksi MySQL-tietokannan InnoDB-tallennusmoottorin tärkeimmistä osista. Tietokannan suorituskykyä ja tehokkuutta voidaan parantaa merkittävästi.
MySQL-prosessi sisältää useita linkkejä asiakkaan ja MySQL-palvelimen välisestä yhteydestä SQL-lauseiden suorittamiseen, optimointiin, tietojen lukemiseen ja tulosten palauttamiseen. Seuraavassa on yksityiskohtainen yleiskatsaus MySQL-prosessista:
Liitin (yhteydenhallinta):
Kun asiakas (kuten sovellus tai komentorivityökalu) pyytää yhteyttä MySQL-palvelimeen, MySQL:n liitin on vastuussa näiden yhteyspyyntöjen käsittelystä.
Liitin varmistaa asiakkaan henkilöllisyyden ja käyttöoikeudet, mikä sisältää yleensä käyttäjänimen ja salasanan täsmäämisen tarkistamisen.
Jos vahvistus onnistuu, liitin varaa asiakkaalle säikeen (tai istunnon) myöhempiä SQL-toimintoja varten.
Kyselyvälimuisti (Query Cache, huomautus: Tämä moduuli on poistettu MySQL 8.0:sta):
SELECT-kyselyissä MySQL tarkistaa ensin, onko sama kysely ja sen tulokset olemassa kyselyn välimuistissa.
Jos käytössä, MySQL palauttaa tulokset suoraan välimuistiin, jolloin vältetään varsinaisen kyselyn suorittaminen.
Koska kyselyn välimuisti voi kuitenkin aiheuttaa tietojen epäjohdonmukaisuutta (esimerkiksi muut tapahtumat ovat saaneet muokata välimuistissa olevia tietoja), kyselyn välimuistitoiminto on poistettu MySQL 8.0:sta.
Jäsentäjä:
Asiakkaan lähettämä SQL-käsky lähetetään ensin jäsentäjälle.
Jäsentimen tehtävänä on jäsentää SQL-käsky, tarkistaa, onko sen syntaksi oikea, ja muuntaa se sisäiseksi tietorakenteeksi (kuten jäsennyspuuksi tai syntaksipuuksi).
Jos SQL-käskyssä on syntaksivirhe, jäsentäjä palauttaa virhetiedot asiakkaalle.
Esiprosessori:
Joissakin MySQL-versioissa tai tietyissä skenaarioissa voi olla esikäsittelyvaihe.
Esiprosessori vastaa pääasiassa SQL-lauseiden jatkokäsittelystä, kuten taulukon tai kentän olemassaolon tarkistamisesta, SELECT-käskyn *:n laajentamisesta kaikkiin taulukon sarakkeisiin jne.
Optimoija:
Optimoija on vastuussa erilaisten SQL-käskyjen suoritussuunnitelmien arvioinnista ja optimaalisen suoritussuunnitelman valinnasta.
Optimoija ottaa huomioon useita tekijöitä, kuten saatavilla olevat indeksit, liitosmenetelmän tehokkuuden, kyselyn hinnan jne.
Optimoija voi parantaa merkittävästi kyselyn suorituskykyä toimintojen, kuten indeksien, kyselyjen uudelleenjärjestämisen tai kyselyjen yhdistämisen, avulla.
Toteuttaja:
Suoritin suorittaa varsinaiset kyselytoiminnot optimoijan generoiman suoritussuunnitelman perusteella.
Suoritin kutsuu tallennuskoneen (kuten InnoDB) käyttöliittymää lukeakseen tietotaulukon tiedot ja suorittaakseen toimintoja, kuten lajittelua, yhdistämistä ja suodatusta.
Lopuksi suorittaja palauttaa kyselyn tulokset asiakkaalle.
Varastointimoottori:
MySQL tukee useita tallennusmoottoreita, ja jokaisella tallennuskoneella on omat erityiset tietojen tallennus- ja hakumenetelmänsä.
InnoDB on yksi MySQL:n oletustallennusmoottoreista ja tukee edistyneitä tietokantaominaisuuksia, kuten tapahtumien käsittelyä, rivitason lukitsemista ja vierasavaimia.
Kun suorittaja kutsuu tallennuskoneen käyttöliittymää, tallennuskone on vastuussa tietojen lukemisesta levyltä tai tietojen kirjoittamisesta levylle.
Puskuriallas:
InnoDB-tallennuskone käyttää puskurivarastoa taulukkotietojen välimuistiin ja indeksointitietojen vähentämiseen suoran levyn käytön vähentämiseksi.
Puskurivarannon tietosivuja hallitaan käyttötiheyden ja muokkaustilan perusteella välimuistin osumasuhteen ja kyselyn suorituskyvyn parantamiseksi.
Tapahtuma:
MySQL tukee tapahtumien käsittelyä, mikä mahdollistaa useiden toimintojen sitomisen tai palauttamisen kokonaisuutena.
Tapahtuman suorittamisen aikana MySQL tallentaa tarvittavat lokitiedot (kuten redo log ja undo log) varmistaakseen tietojen eheyden ja johdonmukaisuuden.
Jos tapahtuman suoritus onnistuu, kaikki muutokset tallennetaan pysyvästi tietokantaan, jos tapahtuman suoritus epäonnistuu, voit käyttää peruutuslokia suorittaaksesi palautustoiminnon ja palauttaaksesi tiedot tapahtuman alkamista edeltävään tilaan.
MySQL:n prosessi sisältää yhteyden ja autentikoinnin, kyselyn käsittelyn, tietojen tallennuksen ja haun sekä tapahtumien käsittelyn. Optimoimalla näiden linkkien jokainen vaihe MySQL-tietokannan suorituskykyä ja luotettavuutta voidaan parantaa merkittävästi. Samalla MySQL:n suoritusprosessin ymmärtäminen auttaa ymmärtämään paremmin sen sisäistä toimintamekanismia, mikä auttaa paremmin suunnittelemaan ja optimoimaan tietokantaa.
MySQL:n yhteyspooli on tekniikka, jota käytetään tietokantayhteyksien hallintaan ja uudelleenkäyttöön. Se on suunniteltu parantamaan tietokantatoimintojen suorituskykyä ja tehokkuutta erityisesti korkean samanaikaisuuden ympäristöissä. Seuraavassa on yksityiskohtainen selitys MySQL-yhteyspoolista:
MySQL-yhteyspooli muodostaa riittävän määrän tietokantayhteyksiä ohjelman käynnistyessä ja hallitsee näitä yhteyksiä yhtenäisesti muodostaen yhteyspoolin. Kun ohjelman on käytettävä tietokantaa, se hakee dynaamisesti yhteyttä yhteyspoolista ja palauttaa yhteyden yhteyspooliin käytön jälkeen sen sijaan, että se luo ja sulkee yhteyden uudelleen jokaista toimintoa varten.
Vähennä resurssien kulutusta : Tietokantayhteyden luominen ja sulkeminen on suhteellisen aikaa vievä prosessi, joka sisältää TCP-yhteyden kolmisuuntaisen kättelyn ja nelisuuntaisen aallon sekä tietokannan todennusprosessin. Yhteyden yhdistämisen avulla olemassa olevia yhteyksiä voidaan käyttää uudelleen näiden yleiskustannusten vähentämiseksi.
Paranna suorituskykyä : Jos korkean samanaikaisuuden skenaariossa luodaan uusi tietokantayhteys jokaiselle pyynnölle, palvelimen suorituskyky heikkenee merkittävästi. Yhteyspoolin käyttö voi parantaa merkittävästi tietokannan vastausnopeutta ja suorituskykyä.
Vältä liitäntöjen vuotoja : Ilman yhteyspoolia, jos poikkeus tapahtuu, kun ohjelma sulkee yhteyden, se voi aiheuttaa yhteysvuotoja, eli yhteyttä ei suljeta oikein ja se vie järjestelmäresursseja. Yhteysallas voi välttää tämän tilanteen aikakatkaisun kierrätysmekanismin avulla.
alustus: Kun ohjelma käynnistyy, yhteyspooli luo tietyn määrän tietokantayhteyksiä kokoonpanon mukaan ja laittaa nämä yhteydet yhteyspooliin varmuuskopiointia varten.
Hae yhteyttä : Kun ohjelman on päästävä tietokantaan, se hakee yhteyttä yhteyspoolista. Jos yhteyspoolissa on käyttämätön yhteys, se palautetaan suoraan ohjelmaan käytettäväksi, jos tyhjää yhteyttä ei ole, se odottaa tietyn ajan tai palauttaa virheilmoituksen konfiguraation mukaan.
Käytä yhteyttä: Ohjelma käyttää pyydettyä yhteyttä tietokantatoimintojen suorittamiseen.
paluuyhteys : Kun toiminto on valmis, ohjelma palauttaa yhteyden yhteyspooliin. Yhteysvarasto suorittaa yhteydelle tiettyjä tarkistuksia. Jos yhteys on edelleen voimassa, se palautetaan yhteyspooliin, jos yhteys on vanhentunut, se suljetaan ja poistetaan.
Sulje yhteysallas: Kun ohjelma päättyy, kaikki yhteyspoolin yhteydet suljetaan ja varatut järjestelmäresurssit vapautetaan.
Markkinoilla on monia MySQL-yhteyspoolin tarjoajia, joista suosituimpia ovat:
DBCP : Se on avoimen lähdekoodin yhteyspooli toteutus Apache-projektissa, ja se on Tomcatin mukana tuleva yhteyspooli. Se on nopeampi kuin muut yhteyspoolit, mutta se ei välttämättä ole tarpeeksi vakaa.
C3P0 : Se on avoimen lähdekoodin JDBC-yhteyspooli, joka toteuttaa tietolähteen ja JNDI-sidoksen ja tukee JDBC3-standardia ja JDBC2-standardin laajennusta. C3P0:n nopeus on suhteellisen hidas, mutta erittäin vakaa.
druidi (Druid): Se on Alibaban tarjoama avoimen lähdekoodin yhteyspooli. Se yhdistää DBCP:n ja C3P0:n edut ja tarjoaa tehokkaita valvonta- ja laajennustoimintoja. Druid on tällä hetkellä yksi yleisimmin käytetyistä MySQL-yhteyspoolista.
Yhteyspoolin kokoonpano sisältää yleensä seuraavat näkökohdat:
Liitäntöjen enimmäismäärä: Yhteyksien enimmäismäärä, jota yhteyspooli voi hallita.
Liitäntöjen vähimmäismäärä: yhteyspooli käynnistettäessä luotujen yhteyksien alkuperäinen lukumäärä.
Hae yhteyden aikakatkaisu: Enimmäisaika odotusaikana, kun yhteys muodostetaan yhteysvarannosta.
Yhteyden vahvistus: Tarkista yhteyden kelvollisuus ennen yhteyden muodostamista tai yhteyden palauttamista.
Yhteyden kierrätysstrategia: Kierrätä yhteydet niiden jouto- ja käyttöajan perusteella.
Yhteyden yhdistäminen ja säikeiden yhdistäminen ovat kaksi erilaista resurssien yhdistämistekniikkaa, mutta niiden välillä on tietty suhde. Säiepoolia käytetään pääasiassa säieresurssien hallintaan, kun taas yhteyspoolia käytetään tietokantayhteysresurssien hallintaan. Kun säikeen säikeen on suoritettava tietokantatoiminto, se hakee yhteyttä yhteyspoolista toiminnon päätyttyä, yhteys palautetaan yhteyspooliin. Tämä suhde auttaa saavuttamaan tehokkaan resurssien käytön ja yksinkertaistetun hallinnan.
Yhteenvetona voidaan todeta, että MySQL-yhteyspooli on tärkeä tietokantayhteyksien hallintatekniikka. Se tukee vahvasti tietokantatoimintoja käyttämällä yhteyksiä uudelleen, vähentämällä resurssien kulutusta ja parantamalla suorituskykyä. Varsinaisissa sovelluksissa sopiva yhteyspoolin tarjoaja ja konfigurointiparametrit voidaan valita projektin erityistarpeiden ja skenaarioiden mukaan.
MySQL-lokeihin liittyvät haastattelukysymykset voivat kattaa monia näkökohtia, kuten tyypin, roolin, kokoonpanon, lokien optimoinnin ja lokien käytön tietojen palauttamisessa, tietojen replikaatiossa jne. Seuraavassa on joitain yleisiä MySQL-lokiin liittyviä haastattelukysymyksiä ja niiden yksityiskohtaisia vastauksia:
MySQL:n yleisiä lokeja ovat seuraavat:
Virheloki : Tallenna virhetiedot, kun MySQL-palvelin käynnistyy, toimii tai pysähtyy, sekä kaikki tärkeät virhetiedot. Tämä auttaa diagnosoimaan ongelman.
Kyselyloki (yleinen loki) : Tallenna kaikki MySQL-palvelimen vastaanottamat asiakaspyynnöt ja vastaukset, mukaan lukien käyttäjän kirjautumistoiminnot, suoritetut SQL-lauseet jne. Yleensä käytetään auditointiin tai virheenkorjaukseen.
Hidas kyselyloki : Tallenna SQL-käskyt, joiden suoritusaika ylittää kynnyksen, sekä suoritusaika, käytetyt taulukot, käytetyt indeksit ja muut näiden käskyjen tiedot. Käytetään suorituskyvyn säätämiseen ja kyselyn optimointiin.
Binaariloki (lyhyesti Binlog): Tallenna kaikki käskyt, jotka muuttavat tietokannan tietoja (pois lukien käskyt, kuten SELECT ja SHOW), joita käytetään pääasiassa replikointiin ja tietojen palauttamiseen.
Toista loki: InnoDB-tallennusmoottorissa sitä käytetään varmistamaan tapahtumien kestävyys Vaikka järjestelmä kaatuu, tiedot voidaan palauttaa uudelleenlokien avulla.
Kumoa loki: InnoDB-tallennuskoneessa sitä käytetään tietojen tilan tallentamiseen ennen tapahtuman alkamista, jotta tapahtuman epäonnistuessa tai palautuessa tiedot voidaan palauttaa tilaan ennen tapahtuman alkamista.
Rele Loki: MySQL-replikointiarkkitehtuurissa orjapalvelimen välityslokia käytetään pääpalvelimelta vastaanotetun binaarilokin sisällön tallentamiseen.
Hidas kyselyloki voidaan avata ja määrittää MySQL-määritystiedoston (kuten my.cnf tai my.ini) kautta tai se voidaan asettaa dynaamisesti SQL-komennoilla.
Määritystiedostomenetelmä:
Lisää tai muokkaa seuraavat parametrit MySQL-määritystiedostoon:
[mysqld] slow_query_log = 1 slow_query_log_file = /path/to/your/slow-query.log long_query_time = 2
sisään,
slow_query_log
Käytetään ottamaan käyttöön hitaat kyselylokit,
slow_query_log_file
Määritä polku hitaan kyselyn lokitiedostoon,
long_query_time
Aseta niiden SQL-lauseiden suoritusaika, jotka ylittävät hitaiden kyselyjen lokiin tallennettavien sekuntien määrän.
Kun olet muokannut asetustiedostoa, sinun on käynnistettävä MySQL-palvelu uudelleen.
SQL-komentotila:
Hidas kyselyloki voidaan ottaa dynaamisesti käyttöön SQL-komentojen avulla, muttaslow_query_log_filejalong_query_timeParametrit on ehkä asetettava määritystiedoston kautta, koska dynaamisia asetuksia ei ehkä tueta tai ne eivät välttämättä toimi.
Ota hidas kyselyloki käyttöön:
sql复制代码 SET GLOBAL slow_query_log = 'ON';
Huomaa, että SQL-komennoilla dynaamisesti avattu hidas kyselyloki voi muuttua virheelliseksi järjestelmän uudelleenkäynnistyksen jälkeen, joten on suositeltavaa määrittää se asetustiedoston kautta.
Binäärilokeilla (Binlog) on kolme muotoa:
LAUSUNTO : SQL-käskypohjainen replikointi (käskypohjainen toisinnus, SBR). Tässä muodossa MySQL tallentaa suoritetut SQL-lauseet binlogiin. Sen etuna on, että lokimäärä on pieni, mutta se voi kohdata joitain replikointiongelmia, kuten toimintoja, laukaisimia, tallennettuja proseduureja jne., jotka voivat aiheuttaa epäjohdonmukaisuutta isäntä-orjatiedoissa.
RIVI : Rivipohjainen replikointi (RBR). Tässä muodossa MySQL tallentaa muokattujen rivien tietomuutokset. Sen etuna on, että vältetään jotkin replikointiongelmat, mutta lokin määrä voi olla suuri.
SEKATTU : Sekapohjainen replikointi (MBR). MySQL käyttää automaattisesti STATEMENT- tai ROW-muotoa tilanteen mukaan. Mixed-tila on oletustila, ja se on suunniteltu yhdistämään molempien maailmojen parhaat puolet.
Redo Log varmistaa tapahtumien kestävyyden InnoDB-tallennuskoneessa seuraavilla tavoilla:
Kun tapahtuma on lähetetty, InnoDB-moottori tallentaa ensin tapahtuman uudelleenkirjoituslokin muistissa olevaan redo-lokipuskuriin ja päivittää samalla vastaavan tietosivun muistiin.
Kirjoita sitten sopivana ajankohtana redo loki uudelleenlokipuskurissa levyllä olevaan redo-lokitiedostoon. Tämä prosessi on asynkroninen, mutta levyn harjauksen ajoitusta ja taajuutta voidaan ohjata parametreilla.
Jos järjestelmä kaatuu, InnoDB-moottori tarkistaa uudelleenlokitiedoston käynnistyksen yhteydessä ja palauttaa viimeksi lähetetyn tapahtuman muutokset siinä olevien tietueiden perusteella varmistaakseen tietojen kestävyyden.
Näytä lokitiedostot：
virheloki: Tämä voidaan yleensä tehdä katsomalla MySQL-määritystiedostoalog_errorparametri määrittää tiedostopolun virhelokitiedoston paikantamiseksi ja käyttää tekstieditoria tai komentorivityökalua, kutentail、catjne.) nähdäksesi sen sisällön.
Hän on omistautunut teknologian tutkimukselle yli 30 vuoden ajan ja hallitsee useita kieliä, kuten java, linux, javascript, php, css jne. Hän on tehnyt paljon työtä avoimen lähdekoodin alalla Kehittäjän dokumentaatioasema jakaaksesi joitain teknologian kehittämisen ongelmia tulevaa käyttöä varten
