När det gäller MySQL skulle det vara svårt att förstå MyISAM och InnoDB, som är två av de mest välkända och mest använda MySQL-lagringsmotorerna. Idag ska jag prata med er om skillnaden mellan MyISAM och InnoDB i MySQL...
Vad är MyISAM?
MyISAM är standardlagringsmotorn för MySQL:s relationella databashanteringssystem (före 5.5)。 Denna MySQL-tabelllagringsstruktur bygger vidare på många användbara funktioner från den gamla ISAM-koden. I den nya versionen av MySQL ersätter InnoDB-motorn i stor utsträckning MyISAM tack vare dess fördelar vad gäller transaktioner, referensiell integritet och högre samtidighet.
Varje MyISAM-tabell motsvarar tre filer på hårddisken. Alla tre filer har samma filnamn, men har olika fixlelser för att ange deras typsyfte: .frm-filen innehåller definitionen av tabellen, men denna fil är inte en del av MyISAM-motorn, utan en del av servern; .MYD innehåller tabellens data; .MYI är indexfilen för tabellen.
Vad är InnoDB?
InnoDB är en annan lagringsmotor för MySQL, och den nya versionen av standarden som släppts av MySQL AB ingår i alla binära installationspaket.5.5 och framåt som standardlagringsmotor。 Dess fördelar jämfört med andra lagringsmotorer är dess stöd för ACID-kompatibla transaktioner (liknande PostgreSQL) och parameterintegritet (dvs. stöd för främmande nycklar).
Oracle Corporation förvärvade Innobase i oktober 2005. Innobase använder dubbel autentiseringsauktorisation. Det distribueras med GNU och tillåter även andra grupper som vill integrera InnoDB i kommersiell programvara att få en licens.
De mest populära lagringsmotorerna är MyISAM och InnoDB. De största skillnaderna mellan MyISAM och InnoDB är prestanda och transaktionskontroll. MyISAM är en utökad implementation av den tidiga ISAM (Indexed Sequential Access Method, ISAM stöds inte längre efter MySQL 5.0), ISAM är utformad för att hantera situationer där läsfrekvensen är mycket högre än skrivfrekvensen, så ISAM och senare MyISAM tar inte hänsyn till stödet för saker, utesluter TPM, behöver inga transaktionsposter, ISAM:s frågeeffektivitet är betydande och minnesförbrukningen är mycket liten.
MyISAM ärver dessa fördelar samtidigt som det håller sig uppdaterad med ett stort antal användbara nya funktioner och relaterade verktyg. Till exempel, med hänsyn till samtidighetskontroll, finns tabellnivålås, och även om MyISAM i sig inte stöder feltolerans kan det användas för att återställa fel via myisamchk. Och eftersom MyISAM använder sina egna oberoende lagringsfiler (MYD-datafil och MYI-indexfil) för varje tabell, är det mycket smidigt att säkerhetskopiera och återställa (kopieringsöverskrivning räcker), och det stöder även online-återställning. Jämfört med andra lagringsmotorer har MyISAM de flesta verktyg för att kontrollera och reparera tabeller. MyISAM-tabeller kan komprimeras och de stödjer fulltextsökning. De är inte transaktionssäkra och stöder inte främmande nycklar, så om din applikation inte kräver transaktioner och bara hanterar grundläggande CRUD-operationer är MyISAM vägen att gå.
InnoDB är utformat för läsning och skrivning med hög samtidighet, med MVCC (Multi-Version Concurrency Control) och radlås för att ge ACID-kompatibelt transaktionsstöd. InnoDB stöder integritet för främmande nyckelreferenser och har möjligheter till felåterställning. Dessutom är prestandan hos InnoDB faktiskt ganska bra, särskilt vid bearbetning av stora datamängder, enligt officiella termer: InnoDB:s CPU-effektivitet är ojämförlig med andra diskbaserade relationsdatabaser. Dock är InnoDBs säkerhetskopiering och återställning lite mer besvärlig, om du inte använder Multilit-tablespace-stödet som ges av version 4.1 eller senare, eftersom InnoDB:s datafiler till skillnad från MyISAM inte motsvarar varje tabell oberoende. Istället används det delade tabellutrymmet, och den enkla metoden för kopieringsöverskrivning är inte lämplig för honom, och datan måste återställas efter att MYSQL har stoppats. Att använda per-table tablespacesd gör att varje tabell motsvarar en separat tabellrymdfil, situationen är mycket enklare. Den har samma egenskaper som BDB-typer, och de stödjer också främmande nycklar. InnoDB-tabeller är snabba och har rikare funktioner än BDB, så det rekommenderas om du behöver en transaktionssäkert lagringsmotor.
Generellt är InnoDB ett bra val om transaktionsstöd behövs och har hög samtidig läs- och skrivfrekvens. BDB kan betraktas om frekvensen av samtidiga läsningar och skrivningar inte är hög, men BDB kommer inte längre att stödjas i MySQL 5.1 och senare versioner. Det här alternativet är borta
Som standard är InnoDB-transaktioner öppna (sätt autocommit = 0), vilket innebär att varje gång en post infogas kommer InnoDB-tabellen att behandla den som en separat transaktion. Så om vi infogar 10 000 poster och inte stänger transaktionen, kommer InnoDB-typtabellen att behandla det som 10 000 transaktioner, och den totala insättningstiden vid denna tidpunkt är lång, vid denna tidpunkt måste vi stänga av transaktionen först och sedan infoga den, så hastigheten kommer att vara mycket snabb. När det gäller Heap och BDB (Berkeley DB) är penetrationsgraden relativt sett inte lika bra som de två tidigare, men i vissa fall, Heap-lagringsmotorn är fortfarande mycket tillämplig, som lagrar data i minnet, och är extremt snabb eftersom det inte finns någon disk-I/O-väntan. Men eftersom det är en minneslagringsmotor kommer alla ändringar som görs att försvinna efter att servern startas om. Heap är en utmärkt plats att använda BDB för testning, eftersom det är MySQLS första transaktionssäkra lagringsmotor. Byggt på Berkeley DB-databasbiblioteket är det också transaktionssäkert, men BDB är uppenbarligen inte lika populärt som InnoDB, eftersom de flesta lagringsmotorer i MySQL som stödjer transaktioner också letar efter MVCC- eller radnivålåsningsmotorer, medan BDB endast stöder Page-level Lock.
InnoDB-motor
InnoDB är en transaktionell lagringsmotor som stödjer rollbacks och är designad för att tillhandahålla högpresterande tjänster vid bearbetning av stora datamängder, och den etablerar buffertpooler i minnet vid körning för att buffra data och index.
InnoDB-motorns fördelar:
1. Stödja transaktionshantering och ACID-transaktionsfunktioner;
2. Fyra isoleringsnivåer av SQL-standard realiseras;
3. Stöd för radnivålås och främmande nyckelbegränsningar;
4. Du kan använda transaktionsloggar för dataåterställning.
5. Låsnivån är radlås, vilket är lämpligt för frekvent bordsändring med hög samtidighet, och hög samtidighet är bättre än MyISAM. Nackdelen är att systemets konsumtion är stor.
6. Indexet cachar inte bara sig självt utan cachar även data, vilket kräver mer minne än MyISAM.
InnoDB-motorns nackdelar:
Eftersom den inte sparar antalet rader i tabellen skannas hela tabellen när COUNT-statistik används.
MyISAM-motor
MyISAM är standardmotorn före MySQL 5.5.5 och är designad för att läsa snabbt.
Fördelar med MyISAM-motorn:
1. Högpresterande läsning;
2. Eftersom det sparar antalet rader i tabellen kommer hela tabellen inte att skannas när COUNT-statistik används;
Nackdelar med MyISAM-motorn:
1. Låsnivån är ett bordslås, och fördelen med klocklåset är att taket är litet och låset är snabbt; Nackdelarna är att låsgranulariteten är stor, sannolikheten för låsimpuls är hög och samtidighetskapaciteten är låg, vilket är lämpligt för frågebaserade tjänster.
2. Denna motor stöder inte transaktioner eller främmande nycklar.
3. INSERT- och UPDATE-operationer måste låsa hela tabellen;
4. Den lagrar antalet rader i tabellen, så när den VÄLJER ANTAL(*) FRÅN TABELLEN behöver den bara läsa de sparade värdena direkt utan att skanna hela tabellen.
Tillämpliga scenarier
MyISAM är lämplig för: (1) att göra många räkningsberäkningar; (2) Sällsynta insättningar och mycket frekventa frågor; (3) Det finns inget företag.
InnoDB är lämpligt för: (1) höga tillförlitlighetskrav eller transaktioner; (2) Tabelluppdateringar och frågor är ganska frekventa, och risken för tabelllåsning är relativt hög.
Tabelljämförelse
| Egenskaper | MyISAM | Heap | BDB | InnoDB | | Transaktioner | Ej stödd | Ej stödd | Stöttar någon | Stöttar någon | | Låsgranularitet | Bordslås | Bordslås | Page Lock (sida, 8KB) | Lås | | lagring | Dela filer | I minnet | En fil per tabell | Tabellutrymme | | Isoleringsnivå | inte | inte | Läs Engagerad | Alla | | Portabelt format | vara | Ej tillgängligt | inte | vara | | Citeringsfullständighet | inte | inte | inte | vara | | Datans primärnyckel | inte | inte | vara | vara | | MySQL cacher dataposter | inte | Ja | Ja | Ja | | användbarhet | Fullständig version | Fullständig version | MySQL-Max | Fullständig version |
Vissa skillnader i detaljer
1. InnoDB stöder inte index av FULLTEXT-typ, vilket har stödts sedan MySQL 5.6 (experimentellt).
2. InnoDB sparar inte det specifika antalet rader i tabellen, det vill säga, när select-count() från tabellen exekveras måste InnoDB skanna hela tabellen för att räkna ut hur många rader det finns, men MyISAM behöver bara läsa ut antalet sparade rader. Observera att när count()-satsen innehåller ett where-villkor, är operationen densamma för båda tabellerna.
3. För fält av AUTO_INCREMENT typ måste InnoDB innehålla ett index med endast det fältet, men i MyISAM-tabellen kan du skapa ett gemensamt index med andra fält.
4. När DELETE FROM-tabellen används kommer InnoDB inte att återskapa tabellen, utan radera den rad för rad.
5. LOAD TABLE FROM MASTER-operationen fungerar inte för InnoDB, lösningen är att först byta InnoDB-tabellen till MyISAM-tabellen, importera datan och sedan ändra den till InnoDB-tabellen, men den är inte tillämplig på tabellen som använder ytterligare InnoDB-funktioner (såsom främmande nycklar).
6. Dessutom är radlåset i InnoDB-tabellen inte absolut; om MySQL inte kan bestämma vilket intervall som ska skannas vid exekvering av en SQL-sats, kommer InnoDB-tabellen också att låsa hela tabellen.
7. InnoDB stöder inte fulltextindexering, medan MyISAM gör det. Fulltextindexering innebär att skapa ett omvänd ordningsindex för varje ord i char, varchar och text (förutom stoppord). MyISAM:s fulltextindex är faktiskt värdelöst, eftersom det inte stöder kinesisk ordsegmentering och måste skrivas till datatabellen av användaren efter ordsegmentering, och ord med färre än 4 kinesiska tecken ignoreras som stoppord.
|
Publicerad på 2020-04-13 09:53:49
|
|
|
