Når det gjelder MySQL, vil det være vanskelig å forstå MyISAM og InnoDB, som er to av de mest kjente og mest brukte MySQL-lagringsmotorene. I dag skal jeg snakke med dere om forskjellen mellom MyISAM og InnoDB i MySQL...
Hva er MyISAM?
MyISAM er standard lagringsmotor for MySQL-systemet for relasjonsdatabaseadministrasjon (før 5.5)。 Denne MySQL-tabelllagringsstrukturen utvider mange nyttige funksjoner fra den gamle ISAM-koden. I den nye versjonen av MySQL erstatter InnoDB-motoren MyISAM i stor grad på grunn av dens fordeler når det gjelder transaksjoner, referanseintegritet og høyere samtidighet.
Hver MyISAM-tabell tilsvarer tre filer på harddisken. Alle tre filene har samme filnavn, men har ulike endelser for å indikere typeformålet: .frm-filen inneholder definisjonen av tabellen, men denne filen er ikke en del av MyISAM-motoren, men en del av serveren; .MYD inneholder tabellens data; .MYI er indeksfilen til tabellen.
Hva er InnoDB?
InnoDB er en annen lagringsmotor for MySQL, og den nye versjonen av standarden utgitt av MySQL AB er inkludert i alle binære installasjonspakker.5.5 og utover som standard lagringsmotor。 Fordelene over andre lagringsmotorer er støtte for ACID-kompatible transaksjoner (lignende PostgreSQL) og parameterintegritet (dvs. støtte for fremmednøkler).
Oracle Corporation kjøpte Innobase i oktober 2005. Innobase bruker dobbel autentiseringsautorisasjon. Den distribueres via GNU og lar også andre grupper som ønsker å inkorporere InnoDB i kommersiell programvare å skaffe lisens.
De mest populære lagringsmotorene er MyISAM og InnoDB. De viktigste forskjellene mellom MyISAM og InnoDB er ytelse og transaksjonskontroll. MyISAM er en utvidet implementering av den tidlige ISAM (Indexed Sequential Access Method, ISAM støttes ikke lenger etter MySQL 5.0), ISAM er designet for å håndtere situasjoner der lesefrekvensen er mye høyere enn skrivefrekvensen, så ISAM og senere MyISAM tar ikke hensyn til støtte for ting, utelukker TPM, trenger ikke transaksjonsposter, ISAM-spørringseffektiviteten er betydelig, og minneforbruket er svært lite.
MyISAM arver disse fordelene samtidig som det holder tritt med et stort antall nyttige nye funksjoner og relaterte verktøy. For eksempel, med tanke på samtidighetskontroll, tilbys tabellnivå-låser, og selv om MyISAM i seg selv ikke støtter feiltoleranse, kan det brukes til å gjenopprette feil gjennom myisamchk. Og siden MyISAM bruker sine egne uavhengige lagringsfiler (MYD-datafil og MYI-indeksfil) for hver tabell, er det veldig praktisk å sikkerhetskopiere og gjenopprette (kopioverskriving er tilstrekkelig), og det støtter også nettbasert gjenoppretting. Sammenlignet med andre lagringsmotorer har MyISAM de fleste verktøy for å sjekke og reparere tabeller. MyISAM-tabeller kan komprimeres, og de støtter fulltekstsøk. De er ikke transaksjonssikre, og de støtter ikke fremmednøkler, så hvis applikasjonen din ikke krever transaksjoner og kun håndterer grunnleggende CRUD-operasjoner, er MyISAM veien å gå.
InnoDB er designet for høysamtidige lese- og skrivesituasjoner, ved bruk av MVCC (Multi-Version Concurrency Control) og radlåser for å gi ACID-kompatibel transaksjonsstøtte. InnoDB støtter fremmednøkkelreferanseintegritet og har feilgjenopprettingsmuligheter. I tillegg er ytelsen til InnoDB faktisk ganske god, spesielt når man behandler store datamengder, i offisielle termer: InnoDBs CPU-effektivitet er ikke sammenlignbar med andre diskbaserte relasjonsdatabaselagringsmotorer. Imidlertid er sikkerhetskopiering og gjenoppretting av InnoDB litt mer problematisk, med mindre du bruker Multilit-tablespace-støtten som tilbys av versjon 4.1 eller nyere, fordi i motsetning til MyISAM, tilsvarer ikke InnoDBs datafiler hver tabell uavhengig. I stedet brukes det delte tabellrommet, og den enkle kopioverskrivingsmetoden er ikke egnet for ham, og dataene må gjenopprettes etter at MYSQL er stoppet. Ved å bruke per-table tablespacesd tilsvarer hver tabell en egen tablespace-fil, situasjonen er mye enklere. Den har de samme egenskapene som BDB-typer, og de støtter også fremmednøkler. InnoDB-tabeller er raske og har rikere funksjoner enn BDB, så det anbefales hvis du trenger en transaksjonssikker lagringsmotor.
Generelt er InnoDB et godt valg hvis transaksjonsstøtte er nødvendig og har høy samtidig lese- og skrivefrekvens. BDB kan vurderes hvis frekvensen av samtidige lesinger og skrivinger ikke er høy, men BDB vil ikke lenger støttes i MySQL 5.1 og senere versjoner. Dette alternativet er borte
Som standard er InnoDB-transaksjoner åpne (sett autocommit = 0), noe som betyr at hver gang en post legges inn, vil InnoDB-tabellen behandle den som en separat transaksjon. Så hvis vi setter inn 10 000 poster og ikke lukker transaksjonen, vil InnoDB-typetabellen behandle det som 10 000 transaksjoner, og den totale innsettingstiden på dette tidspunktet er mye, på dette tidspunktet må vi først slå av transaksjonen og deretter sette den inn, så hastigheten vil være veldig rask. Når det gjelder Heap og BDB (Berkeley DB), relativt sett, er penetrasjonsraten ikke like god som de to foregående, men i noen tilfeller, Heap-lagringsmotoren er fortsatt svært anvendelig, som lagrer data i minnet, og er ekstremt rask fordi det ikke er disk-I/O-venting. Men siden det er en minnelagringsmotor, vil alle endringer forsvinne etter at serveren starter på nytt. Heap er et flott sted å bruke BDB til testing, siden det er MySQLS første transaksjonssikre lagringsmotor. Bygget på grunnlag av Berkeley DB-databasebiblioteket, er det også transaksjonssikkert, men BDB er åpenbart ikke like populært som InnoDB, fordi de fleste lagringsmotorene i MySQL som støtter transaksjoner også ser etter MVCC- eller radnivå-låsemotorer, mens BDB kun støtter Page-level Lock.
InnoDB-motoren
InnoDB er en transaksjonell lagringsmotor som støtter tilbakerulling og er designet for å tilby høyytelsestjenester ved behandling av store datamengder, og den etablerer bufferpooler i minnet under kjøring for å buffere data og indekser.
Fordeler med InnoDB-motoren:
1. Støtte transaksjonsbehandling og ACID-transaksjonsfunksjoner;
2. Fire isolasjonsnivåer av SQL-standarden realiseres;
3. Støtte radnivå-lås og fremmednøkkelbegrensninger;
4. Du kan bruke transaksjonslogger for datagjenoppretting.
5. Låsenivået er radlås, som egner seg for hyppig bordmodifikasjon med høy samtidighet, og høy samtidighet er bedre enn MyISAM. Ulempen er at systemforbruket er stort.
6. Indeksen cacher ikke bare seg selv, men cacher også data, noe som krever mer minne enn MyISAM.
Ulemper med InnoDB-motoren:
Fordi den ikke lagrer antall rader i tabellen, blir hele tabellen skannet når man bruker COUNT-statistikk.
MyISAM-motoren
MyISAM er standardmotoren før MySQL 5.5.5 og er designet for å lese raskt.
Fordeler med MyISAM-motoren:
1. Høyytelseslesning;
2. Fordi den lagrer antall rader i tabellen, vil ikke hele tabellen bli skannet når man bruker COUNT-statistikk;
Ulemper med MyISAM-motoren:
1. Låsenivået er en bordlås, og fordelen med klokkelåsen er at overheaden er liten og låsen rask; Ulempene er at låsegranulariteten er stor, sannsynligheten for låseimpuls er høy, og samtidighetskapasiteten er lav, noe som egner seg for spørringsbaserte tjenester.
2. Denne motoren støtter ikke transaksjoner eller fremmednøkler.
3. INSERT- og UPDATE-operasjoner må låse hele tabellen;
4. Den lagrer antall rader i tabellen, så når den VELGER TELL(*) FRA TABELLEN, trenger den bare å lese de lagrede verdiene direkte uten å skanne hele tabellen.
Gjeldende scenarier
MyISAM egner seg til: (1) å gjøre mange telleberegninger; (2) Sjelden innsetting og svært hyppige forespørsler; (3) Det finnes ingen forretninger.
InnoDB er egnet for: (1) høye pålitelighetskrav eller transaksjoner; (2) Tabelloppdateringer og forespørsler er ganske hyppige, og sjansen for tabelllåsing er relativt høy.
Tabellsammenligning
| Egenskaper | MyISAM | Heap | BDB | InnoDB | | Transaksjoner | Ikke støttet | Ikke støttet | I tanken | I tanken | | Låsegranularitet | Bordlås | Bordlås | Sidelås (side, 8KB) | Lås | | lagring | Delte filer | til minne | Én fil per tabell | Tabellrom | | Isolasjonsnivå | ikke | ikke | Les Committed | Alle | | Bærbart format | være | Ikke tilgjengelig | ikke | være | | Fullstendighet av sitater | ikke | ikke | ikke | være | | Dataprimærnøkkel | ikke | ikke | være | være | | MySQL cacher dataposter | ikke | Ja | Ja | Ja | | Brukervennlighet | Fullversjon | Fullversjon | MySQL-Max | Fullversjon |
Noen forskjeller i detaljer
1. InnoDB støtter ikke indekser av FULLTEXT-typen, som har vært støttet siden MySQL 5.6 (eksperimentell).
2. InnoDB lagrer ikke det spesifikke antallet rader i tabellen, det vil si at når man utfører select count() fra tabellen, må InnoDB skanne hele tabellen for å beregne hvor mange rader det er, men MyISAM trenger bare å lese opp antall lagrede rader. Merk at når count()-setningen inneholder en where-betingelse, er operasjonen den samme for begge tabellene.
3. For felt av AUTO_INCREMENT type må InnoDB inneholde en indeks med kun det feltet, men i MyISAM-tabellen kan du lage en felles indeks med andre felt.
4. Når DELETE FROM-tabellen, vil ikke InnoDB gjenopprette tabellen, men slette den linje for linje.
5. LOAD TABLE FROM MASTER-operasjonen fungerer ikke for InnoDB, løsningen er først å endre InnoDB-tabellen til MyISAM-tabellen, importere dataene, og deretter endre den til InnoDB-tabellen, men den er ikke relevant for tabellen som bruker ekstra InnoDB-funksjoner (som fremmednøkler).
6. I tillegg er radlåsen i InnoDB-tabellen ikke absolutt; hvis MySQL ikke kan bestemme området som skal skannes når en SQL-setning kjøres, vil InnoDB-tabellen også låse hele tabellen.
7. InnoDB støtter ikke fulltekstindeksering, mens MyISAM gjør det. Fulltekstindeksering refererer til å lage en omvendt indeks for hvert ord i char, varchar og text (bortsett fra stoppord). MyISAMs fulltekstindeks er faktisk ubrukelig, fordi den ikke støtter kinesisk ordsegmentering, og må skrives til datatabellen av brukeren etter ordsegmentering, og ord med færre enn 4 kinesiske tegn vil bli ignorert som stoppord.
|
Publisert på 13.04.2020 09:53:49
|
|
|
