Når det gælder MySQL, ville det være svært at forstå MyISAM og InnoDB, som er to af de mest kendte og udbredte MySQL-lagringsmotorer. I dag vil jeg tale med dig om forskellen mellem MyISAM og InnoDB i MySQL...
Hvad er MyISAM?
MyISAM er standardlagringsmotoren for MySQL relationelle databasestyringssystem (før 5.5)。 Denne MySQL-tabellagringsstruktur udvider mange nyttige funktioner fra den gamle ISAM-kode. I den nye version af MySQL erstatter InnoDB-motoren i vid udstrækning MyISAM på grund af dens fordele i forhold til transaktioner, referentieel integritet og højere samtidighed.
Hver MyISAM-tabel svarer til tre filer på harddisken. Alle tre filer har samme filnavn, men har forskellige endelser for at angive deres typeformål: .frm-filen indeholder definitionen af tabellen, men denne fil er ikke en del af MyISAM-motoren, men en del af serveren; .MYD indeholder tabellens data; .MYI er indeksfilen for tabellen.
Hvad er InnoDB?
InnoDB er en anden lagringsmotor for MySQL, og den nye version af standarden udgivet af MySQL AB er inkluderet i alle binære installationspakker.5.5 og frem som standard lagringsmotor。 Dens fordele i forhold til andre lagringsmotorer er understøttelsen af ACID-kompatible transaktioner (svarende til PostgreSQL) og parameterintegritet (dvs. understøttelse af fremmednøgler).
Oracle Corporation opkøbte Innobase i oktober 2005. Innobase bruger dobbelt autentificeringsautorisation. Det distribueres via GNU og giver også andre grupper, der ønsker at inkorporere InnoDB i kommerciel software, mulighed for at opnå en licens.
De mest populære lagringsmotorer er MyISAM og InnoDB. De vigtigste forskelle mellem MyISAM og InnoDB er ydeevne og transaktionskontrol. MyISAM er en udvidet implementering af den tidlige ISAM (Indexed Sequential Access Method, ISAM understøttes ikke længere efter MySQL 5.0), ISAM er designet til at håndtere situationer, hvor læsefrekvensen er meget højere end skrivefrekvensen, så ISAM og senere MyISAM tager ikke hensyn til understøttelse af ting, udelukker TPM, ikke behøver transaktionsposter, ISAM-forespørgselseffektiviteten er betydelig, og hukommelsesforbruget er meget lille.
MyISAM arver disse fordele, samtidig med at det følger med i tiden med et stort antal nyttige nye funktioner og relaterede værktøjer. For eksempel, med hensyn til samtidighedskontrol, tilbydes der tabelniveau-låse, og selvom MyISAM i sig selv ikke understøtter fejltolerance, kan den bruges til at genoprette fejl via myisamchk. Og da MyISAM bruger sine egne uafhængige lagringsfiler (MYD-datafil og MYI-indeksfil) for hver tabel, er det meget bekvemt at tage backup og gendanne (kopioverskrivning er tilstrækkeligt), og det understøtter også online gendannelse. Sammenlignet med andre lagringsmotorer har MyISAM de fleste værktøjer til kontrol og reparation af tabeller. MyISAM-tabeller kan komprimeres, og de understøtter fuldtekstsøgning. De er ikke transaktionssikre, og de understøtter ikke fremmednøgler, så hvis din applikation ikke kræver transaktioner og kun håndterer basale CRUD-operationer, er MyISAM vejen frem.
InnoDB er designet til læse- og skrivesituationer med høj samtidighed og bruger MVCC (Multi-Version Concurrency Control) og række-niveau låse for at give ACID-kompatibel transaktionsunderstøttelse. InnoDB understøtter integritet af fremmednøglereferencer og har fejlgendannelsesmuligheder. Derudover er ydeevnen i InnoDB faktisk ret god, især ved behandling af store datamængder, ifølge officielle termer: InnoDBs CPU-effektivitet er usammenlignelig med andre diskbaserede relationelle databaselagringsmotorer. Dog er InnoDB's backup og gendannelse lidt mere besværlig, medmindre du bruger Multilit-tablespace-understøttelsen fra version 4.1 eller nyere, for i modsætning til MyISAM svarer InnoDBs datafiler ikke til hver tabel uafhængigt. I stedet bruges det delte tabelområde, og den simple kopioverskrivningsmetode er ikke egnet for ham, og dataene skal gendannes efter at have stoppet MYSQL. Ved at bruge per-table tablespacesd svarer hver tabel til en separat tablespace-fil, situationen er meget enklere. Den har de samme egenskaber som BDB-typer, og de understøtter også fremmednøgler. InnoDB-tabeller er hurtige og har rigere funktioner end BDB, så det anbefales, hvis du har brug for en transaktionssikkert lagringsmotor.
Generelt er InnoDB et godt valg, hvis transaktionsunderstøttelse er nødvendig, og har en høj samtidig læse- og skrivehyppighed. BDB kan overvejes, hvis hyppigheden af samtidige læsninger og skrivninger ikke er høj, men BDB vil ikke længere blive understøttet i MySQL 5.1 og senere versioner. Denne mulighed er væk
Som standard er InnoDB-transaktioner åbne (sæt autocommit = 0), hvilket betyder, at hver gang en post indsættes, vil InnoDB-tabellen behandle den som en separat transaktion. Så hvis vi indsætter 10.000 poster og ikke lukker transaktionen, vil InnoDB-typetabellen behandle det som 10.000 transaktioner, og den samlede indsættelsestid på dette tidspunkt er meget, på dette tidspunkt skal vi først slukke for transaktionen og derefter indsætte den, så hastigheden vil være meget hurtig. Hvad angår Heap og BDB (Berkeley DB), relativt set er penetrationsraten ikke så god som de to foregående, men i nogle tilfælde, Heap-lagringsmotoren er stadig meget anvendelig, som gemmer data i hukommelsen, og den er ekstremt hurtig, fordi der ikke er nogen disk-I/O-ventetid. Men da det er en hukommelseslagringsmotor, vil alle ændringer forsvinde, når serveren genstarter. Heap er et fantastisk sted at bruge BDB til test, da det er MySQLS første transaktionssikre lagringsmotor. Bygget på baggrund af Berkeley DB-databasebiblioteket er det også transaktionssikkert, men BDB er åbenlyst ikke lige så populært som InnoDB, fordi de fleste lagringsmotorer i MySQL, der understøtter transaktioner, også leder efter MVCC- eller række-niveau låsings-lagringsmotorer, mens BDB kun understøtter Page-level Lock.
InnoDB-motoren
InnoDB er en transaktionel lagringsmotor, der understøtter rollbacks og er designet til at levere højtydende tjenester ved behandling af store datamængder, og den etablerer bufferpuljer i hukommelsen under kørsel for at buffere data og indekser.
Fordele ved InnoDB-motoren:
1. Understøtte transaktionsbehandling og ACID-transaktionsfunktioner;
2. Fire isolationsniveauer af SQL-standarden realiseres;
3. Understøtte række-niveau lås- og fremmednøglebegrænsninger;
4. Du kan bruge transaktionslogfiler til datagendannelse.
5. Låseniveauet er rækkelås, hvilket egner sig til hyppig tabelændring med høj samtidighed, og høj samtidighed er bedre end MyISAM. Ulempen er, at systemets forbrug er stort.
6. Indekset cacher ikke kun sig selv, men cacher også data, hvilket kræver mere hukommelse end MyISAM.
Ulemper ved InnoDB-motoren:
Da den ikke gemmer antallet af rækker i tabellen, scannes hele tabellen ved brug af COUNT-statistikker.
MyISAM-motoren
MyISAM er standardmotoren før MySQL 5.5.5 og er designet til at læse hurtigt.
MyISAM-motorens fordele:
1. Højtydende læsning;
2. Fordi det gemmer antallet af rækker i tabellen, vil hele tabellen ikke blive scannet, når man bruger COUNT-statistikker;
Ulemper ved MyISAM-motoren:
1. Låseniveauet er en bordlås, og fordelen ved urlåsen er, at overhænget er lille, og låsen er hurtig; Ulemperne er, at låsegranulariteten er stor, sandsynligheden for låseimpuls er høj, og samtidighedskapaciteten er lav, hvilket er velegnet til forespørgselsbaserede tjenester.
2. Denne motor understøtter ikke transaktioner eller fremmednøgler.
3. INSERT- og UPDATE-operationer skal låse hele tabellen;
4. Den gemmer antallet af rækker i tabellen, så når den VÆLGER TÆLLING(*) FRA TABELLEN, behøver den kun at læse de gemte værdier direkte uden at scanne hele tabellen.
Relevante scenarier
MyISAM er velegnet til: (1) at udføre mange tælleberegninger; (2) Sjælden indsættelse og meget hyppige forespørgsler; (3) Der er ingen forretning.
InnoDB er velegnet til: (1) høje pålidelighedskrav eller transaktioner; (2) Tabelopdateringer og forespørgsler er ret hyppige, og chancen for tabellåsning er relativt høj.
Tabel sammenligning
| Egenskaber | MyISAM | Bunke | BDB | InnoDB | | Transaktioner | Ikke understøttet | Ikke understøttet | Støtte nogen | Støtte nogen | | Låsegranularitet | Bordlås | Bordlås | Page Lock (side, 8KB) | Lås | | oplagring | Split-filer | i mindet | Én fil pr. tabel | Tablespace | | Isolationsniveau | ikke | ikke | Læs Forpligtet | Alle | | Bærbart format | være | Ikke tilgængeligt | ikke | være | | Kildehenvisningsfuldstændighed | ikke | ikke | ikke | være | | Dataprimærnøgle | ikke | ikke | være | være | | MySQL cacher dataposter | ikke | Ja | Ja | Ja | | brugervenlighed | Fuld version | Fuld version | MySQL-Max | Fuld version |
Nogle forskelle i detaljer
1. InnoDB understøtter ikke indekser af FULLTEXT-typen, hvilket har været understøttet siden MySQL 5.6 (eksperimentelt).
2. InnoDB gemmer ikke det specifikke antal rækker i tabellen, det vil sige, når select-count() fra tabellen udføres, skal InnoDB scanne hele tabellen for at beregne, hvor mange rækker der er, men MyISAM behøver blot at læse antallet af gemte rækker op. Bemærk, at når count()-sætningen indeholder en where-betingelse, er operationen den samme for begge tabeller.
3. For felter af AUTO_INCREMENT type skal InnoDB indeholde et indeks med kun det felt, men i MyISAM-tabellen kan du oprette et fælles indeks med andre felter.
4. Når DELETE FROM tabellen, vil InnoDB ikke genskabe tabellen, men slette den linje for linje.
5. LOAD TABLE FROM MASTER-operationen virker ikke for InnoDB, løsningen er først at ændre InnoDB-tabellen til MyISAM-tabellen, importere dataene og derefter ændre den til InnoDB-tabellen, men den er ikke anvendelig for den tabel, der bruger yderligere InnoDB-funktioner (såsom fremmednøgler).
6. Derudover er rækkelåsen i InnoDB-tabellen ikke absolut; hvis MySQL ikke kan bestemme det område, der skal scannes ved udførelse af en SQL-sætning, vil InnoDB-tabellen også låse hele tabellen.
7. InnoDB understøtter ikke fuldtekstindeksering, mens MyISAM gør. Fuldtekstindeksering refererer til at skabe et omvendt indeks for hvert ord i char, varchar og tekst (undtagen stopord). MyISAMs fuldtekstindeks er faktisk ubrugeligt, fordi det ikke understøtter kinesisk ordsegmentering og skal skrives til datatabellen af brugeren efter ordsegmentering, og ord med færre end 4 kinesiske tegn vil blive ignoreret som stopord.
|
Opslået på 13/04/2020 09.53.49
|
|
|
