En viktig faktor för databasprestanda är lagringsmotorn som används av databasen, och mer specifikt dess tabeller. Olika lagringsmotorer ger bättre prestanda i en situation framför en annan. För allmänt bruk finns det två utmanare att överväga. Dessa är MyISAM, som är standard MySQL-lagringsmotor, eller InnoDB, som är en alternativ motor inbyggd i MySQL avsedd för högpresterande databaser. Innan vi kan förstå skillnaden mellan de två lagringsmotorerna måste vi förstå termen "låsning."
Vad är låsning i MySQL?
För att skydda integriteten hos data som lagras i databaser använder MySQL låsning. Låsning, enkelt uttryckt, innebär att skydda data från att nås. När ett lås tillämpas kan data inte ändras utom genom frågan som initierade låset. Låsning är en nödvändig komponent för att säkerställa riktigheten av den lagrade informationen. Varje lagringsmotor har en annan metod för låsning. Beroende på dina data och frågepraxis kan en motor överträffa en annan. I den här serien kommer vi att titta på de två vanligaste typerna av lås som används av våra två lagringsmotorer.
Bordlåsning: Tekniken att låsa en hel tabell när en eller flera celler i tabellen behöver uppdateras eller raderas. Tabelllåsning är standardmetoden som används av standardlagringsmotorn MyISAM.
| Exempel:MyISAM-tabelllåsning | Kolumn A | Kolumn B | Kolumn C | |
| Uppdatering av fråga 1 | Rad 1 | Skriver | data | data |
| Fråga 2 VÄLJ (Vänta) | Rad 2 | data | data | data |
| Uppdatering av fråga 3 (vänta) | Rad 3 | data | data | data |
| Fråga 4 VÄLJ (Vänta) | Rad 4 | data | data | data |
| Fråga 5 SELECT (Vänta) | Rad 5 | data | data | data |
| Exemplet illustrerar hur en enda skrivoperation låser hela tabellen vilket gör att andra frågor väntar på att UPDATE-frågan är klar. |
Låsning på radnivå: Handlingen att låsa ett effektivt radintervall i en tabell medan en eller flera celler inom intervallet ändras eller tas bort. Låsning på radnivå är metoden som används av InnoDB-lagringsmotorn och är avsedd för högpresterande databaser.
| Exempel:InnoDB radnivålåsning | Kolumn A | Kolumn A | Kolumn A | |
| Uppdatering av fråga 1 | Rad 1 | Skriver | data | data |
| Fråga 2 VÄLJ | Rad 2 | Läser | data | data |
| Uppdatering av fråga 3 | Rad 3 | data | Skriver | data |
| Fråga 4 VÄLJ | Rad 4 | Läser | Läser | Läser |
| Fråga 5 SELECT | Rad 5 | Läser | data | Läser |
| Exemplet visar hur låsning på radnivå gör att flera frågor kan köras på enskilda rader genom att endast låsa raderna som uppdateras istället för hela tabellen. |
MyISAM vs. InnoDB
Genom att jämföra de två lagringsmotorerna kommer vi till kärnan i argumentet mellan att använda InnoDB över MyISAM. En applikation eller webbplats som har en ofta använd tabell fungerar exceptionellt bra med InnoDB-lagringsmotorn genom att lösa flaskhalsar med tabelllåsning. Frågan om att använda den ena framför den andra är dock subjektiv eftersom ingen av dem är perfekt i alla situationer. Det finns styrkor och begränsningar för båda lagringsmotorerna. Intim kunskap om databasstrukturen och frågepraxis är avgörande för att välja den bästa lagringsmotorn för dina tabeller.
MyISAM kommer att prestera bättre än InnoDB på stora tabeller som kräver mycket mer läsaktivitet jämfört med skrivaktivitet. MyISAMs läsbarhet överglänser InnoDB eftersom det går snabbare att låsa hela tabellen än att ta reda på vilka rader som är låsta i tabellen. Ju mer information i tabellen, desto mer tid tar det för InnoDB att ta reda på vilka som inte är tillgängliga. Om din applikation förlitar sig på enorma tabeller som inte ändrar data ofta, kommer MyISAM att överträffa InnoDB. Omvänt överträffar InnoDB MyISAM när data i tabellen ändras ofta. Tabelländringar skriver data mer än att läsa data per sekund. I dessa situationer kan InnoDB hänga med i stora mängder förfrågningar lättare än att låsa hela bordet för var och en.
Ska jag använda InnoDB med WordPress, Magento eller Joomla Sites?
Det korta svaret här är ja, i de flesta fall. Liquid Webs mest hjälpsamma människor i värdsupportteam har stött på flera flaskhalsar när kunder använder vissa vanliga webbapplikationer i dag. De flesta användare av populära tredjepartsapplikationer som WordPress, Magento och Joomla har begränsad kunskap om de underliggande databaskomponenterna eller koden som är involverad för att kunna fatta ett välgrundat beslut om lagringsmotorer. De flesta tabelllåsande flaskhalsar från dessa innehållshanteringssystem (CMS) löses i allmänhet genom att ändra alla tabeller för webbplatsen till InnoDB istället för standard MyISAM. Om du är värd för många av dessa typer av CMS på din server skulle det vara fördelaktigt att ändra standardlagringsmotorn i MySQL för att använda InnoDB för alla nya tabeller så att alla nya tabellinstallationer börjar med InnoDB.
Ställa in standardlagringsmotorn
Ställ in din standardlagringsmotor till InnoDB genom att lägga till default_storage_engine=InnoDB till [mysqld] avsnitt av systemkonfigurationsfilen som finns på: /etc/my.cnf. Att starta om MySQL-tjänsten är nödvändigt för att servern ska upptäcka ändringar i filen.
~ $ cat /etc/my.cnf
[mysqld]
log-error=/var/lib/mysql/mysql.err
innodb_file_per_table=1
default-storage-engine=innodb
innodb_buffer_pool_size=128M
Konvertera alla tabeller mellan MyISAM och InnoDB
Tyvärr har MySQL inte i sig ett alternativ att konvertera tabeller, vilket gör att varje tabell kan ändras individuellt. Liquid Webs supportteam har satt ihop en lätt att följa underhållsplan för denna process. Skriptet, som du kan köra på den nödvändiga servern via shell access (SSH) kommer att konvertera alla tabeller mellan lagringsmotorer.
Notera Planera i enlighet med detta när du utför batchoperationer av denna typ ifall driftstopp inträffar. Bästa praxis är att säkerhetskopiera alla dina MySQL-databaser innan du implementerar en förändring av denna storleksordning, vilket ger en enkel återställningspunkt för att förhindra dataförlust.Steg 1: Förberedelser
Planera att börja vid en tidpunkt på dygnet då driftstopp skulle få minimala konsekvenser. Denna process i sig kräver ingen driftstopp, men driftstopp kan vara nödvändig för att återhämta sig från oförutsedda omständigheter.
Steg 2: Säkerhetskopiera alla databaser till en fil
Kommandot nedan skapar en enda filsäkerhetskopiering av alla databaser med namnet all-databases-backup.sqld och kan tas bort när konverteringen har lyckats och det inte finns några uppenbara problem. mysqldump --all-databases > all-databases-backup.sql
Steg 3: Spela in befintliga tabellmotorer till en fil
Kör följande skript för att spela in de befintliga tabellmotorerna till en fil med namnet table-engine-backup.sql . Du kan sedan "importera" eller "köra" den här filen senare för att konvertera tillbaka till sina ursprungliga motorer om det behövs.
mysql -Bse 'SELECT CONCAT("ALTER TABLE ",table_schema,".",table_name," ENGINE=",Engine,";") FROM information_schema.tables WHERE table_schema NOT IN("mysql","information_schema","performance_schema");' | tee table-engine-backup.sql
Om du av någon anledning behöver återställa tabellmotorerna, kör:mysql < table-engine-backup.sql
Steg 4a: Konvertera MyISAM-tabeller till InnoDB
Kommandot nedan fortsätter även om en tabell misslyckas och låter dig veta vilka tabeller som misslyckades med att konvertera. Utdata sparas i filen med namnet convert-to-innodb.log för senare granskningw.
mysql -Bse 'SELECT CONCAT("ALTER TABLE ",table_schema,".",table_name," ENGINE=InnoDB;") FROM information_schema.tables WHERE table_schema NOT IN ("mysql","information_schema","performance_schema") AND Engine = "MyISAM";' | while read -r i; do echo $i; mysql -e "$i"; done | tee convert-to-innodb.log
Steg 4b:Konvertera alla InnoDB-tabeller till MyISAM
Detta kommando fortsätter även om en tabell misslyckas och låter dig veta vilka tabeller som misslyckades med att konvertera. Utdata sparas också i filen med namnet convert-to-myisam.log för senare granskning.
mysql -Bse 'SELECT CONCAT("ALTER TABLE ",table_schema,".",table_name," ENGINE=MyISAM;") FROM information_schema.tables WHERE table_schema NOT IN ("mysql","information_schema","performance_schema") AND Engine = "InnoDB";' | while read -r i; do echo $i; mysql -e "$i"; done | tee convert-to-myisam.log
Konvertera en enda tabell mellan MyISAM och InnoDB
Följande kommandon illustrerar hur konvertering av en enskild tabell går till.
Notera Ersätt databasnamn med rätt databasnamn och tabellnamn med rätt tabellnamn. Se till att du har en giltig säkerhetskopia av tabellen i fråga innan du fortsätter.
Säkerhetskopiera en enskild tabell till en fil mysqldump database_name table_name > backup-table_name.sql
Konvertera en enda tabell till InnoDB
mysql -Bse ‘ALTER TABLE database_name.table_name ENGINE=InnoDB;’
Konvertera en enskild tabell till MyISAM:
mysql -Bse ‘ALTER TABLE database_name.table_name ENGINE=MyISAM;’
Kolla in våra andra artiklar i den här serien, MySQL Performance:Identifying Long Queries, för att lokalisera långsamma frågor i din databas. Håll utkik efter vår nästa artikel där vi kommer att ta upp cachelagring och optimering.