Hoppa till innehåll 
MariaDB-sidan Komprimering minskar det fysiska minnesbehovet genom att InnoDB-sidor komprimeras innan de skrivs till lagringsmediet, vilket leder till en märkbar minskning av I/O-volymerna. Jag visar hur du sparar minne och håller latensen låg, vilka förutsättningar som gäller och vilka inställningar som ger störst effekt i praktiken.
Centrala punkter
Dessa kortfattade punkter ger en inblick i de viktigaste aspekterna.
- Sida för sida Komprimering minskar utrymmesbehovet och I/O.
- Okomprimerad Buffertpoolen begränsar CPU-belastningen i RAM-minnet.
- Flexibel Aktivering per tabell med PAGE_COMPRESSED.
- filsystem-Stöd för Sparse/Hole Punching är obligatoriskt.
- Val av algoritm styr hastighet, latens och CPU-belastning.
Hur InnoDB-sidkomprimering fungerar rent tekniskt
Jag komprimerar varje InnoDB-sida strax innan den skrivs till hårddisken, så att tabellutrymmet endast upptar de faktiskt komprimerade byte och filsystemet markerar lediga områden som ”sparse”. I Buffertpool Jag behåller sidorna okomprimerade, vilket håller CPU-belastningen i arbetsminnet låg och gör att frekventa läsoperationer förblir snabba. Som standard är InnoDB-sidor 16K stora, men de lagrade blocken blir varierande mindre efter komprimeringen, vilket sparar mycket utrymme, särskilt för text- eller JSON-fält. Vid läsning packar jag upp sidan direkt efter att den har laddats in i RAM-minnet, alltså precis vid I/O-gränsen, där besparingen vid överföringen är som störst. På så sätt flyttar jag belastningen från I/O till CPU:n, men endast på de ställen där det är rimligt.
Sidkomprimering jämfört med traditionell InnoDB-tabellkomprimering
Den klassiska komprimeringen bygger på ROW_FORMAT=COMPRESSED i kombination med KEY_BLOCK_SIZE, vilket skapar ett fast komprimerat sidformat och medför en extra beslutsbörda vid skrivning eller uppdatering. Jag föredrar Sidan Komprimering, eftersom den förblir flexibel: Om en komprimering misslyckas kan InnoDB lagra sidan okomprimerad utan att ändra hela filformatet. Buffertpoolen fortsätter att arbeta med okomprimerade 16K-sidor, vilket gör cacheträffar snabba och håller CPU-vägarna enkla. Vid typiska OLTP-arbetsbelastningar med många insättningar och måttliga uppdateringar ger sidkomprimering en bättre balans mellan utrymmesbesparing och latens. Som resultat får jag ofta en märkbar I/O-fördel utan någon hög overhead vid varje Uppdatera till risk.
Förutsättningar och grundkonfiguration
För sidkomprimering krävs InnoDB, och jag aktiverar innodb_file_per_table, så att varje tabell använder sitt eget tabellutrymme. Det avgörande är filsystemet: det måste stödja glesa filer och ”hole-punching”, vilket är fallet med ext4 och XFS och som vanligtvis finns i moderna molnvolymer. För valet av algoritm ställer jag in innodb_compression_algorithm, vanligtvis zlib, lz4 eller lzo, beroende på önskad komprimeringsgrad och CPU-profil. Den som väger in lagringsskiktet drar nytta av en kompakt Jämförelse av filsystem och tar samtidigt hänsyn till drivrutins- och volymalternativ. På så sätt skapas en Konfiguration, som sparar utrymme, minskar I/O-belastningen och fungerar pålitligt.
Aktivering på tabellnivå
Jag aktiverar sidkomprimering per tabell efter att de globala variablerna har ställts in korrekt, så att jag specifikt kan rikta in mig på just de datarader som ger största möjliga nytta. För nya tabeller anger jag alternativen direkt i DDL:n, medan ett ALTER TABLE-kommando sköter omställningen genom omskrivning för befintliga tabeller. Komprimeringsnivån definierar jag med PAGE_COMPRESSION_LEVEL, och beteendet beror på vilken Algoritm . Eftersom övergången tar tid planerar jag in underhållsfönster och kontrollerar utrymmesbehovet med och utan komprimering utifrån verkliga datautdrag. På så sätt kontrollerar jag Utgifter och ett resultat utan överraskningar.
CREATE TABLE log_entries (
id BIGINT UNSIGNED PRIMARY KEY,
created_at DATETIME NOT NULL,
level VARCHAR(20),
message TEXT
) ENGINE=InnoDB
PAGE_COMPRESSED=1
PAGE_COMPRESSION_LEVEL=6;
ALTER TABLE log_entries
ENGINE=InnoDB,
PAGE_COMPRESSED=1;
Lagringsbesparingar i praktiken
Ju mer homogen och textintensiv data är, desto bättre fungerar Kompression; Logg- och rapporteringstabeller ger oftast tydliga effekter. I typiska arbetsbelastningar ser jag ofta 40–60 % mindre upptaget minne med zlib, medan lz4 i många fall klarar 30–50 % och därmed lämnar mer genomströmning över. Starkt distribuerade binära data ger mindre vinst, men även där minskar I/O-volymerna och kostnaderna ofta märkbart. Jag testar alltid med produktionssnapshots på staging för att få fram meningsfulla siffror och upptäcka latensspikar. Resultatet: mindre data på lagringsmediet, kortare överföringstider, bättre Skalning.
Prestanda: Att korrekt bedöma I/O jämfört med CPU
Jag kontrollerar först om flaskhalsen finns på datamediet eller på CPU är avgörande, eftersom valet av komprimeringsmetod beror på detta. I I/O-begränsade miljöer minskar läs- och skrivvolymerna avsevärt, vilket gör att den effektiva prestandan ökar – ofta med endast 5–10 % extra belastning jämfört med okomprimerade tabeller vid användning av snabba algoritmer. CPU-begränsade system drar nytta av lz4 eller lzo, som fungerar mycket snabbt och endast uppnår något lägre komprimeringsgrader. Dessutom beaktar jag Dubbelskrivningsbuffert, eftersom den påverkar skrivbeteendet och tillsammans med sidkomprimering formar I/O-egenskaperna. Eftersom buffertpoolen förblir okomprimerad påverkar frekventa cacheträffar knappt Fördröjning från.
Val av algoritm och komprimeringsnivå
Jag bestämmer Algoritm-Jag väljer komprimeringsmetod utifrån datamönster, läs-/skrivhastighet och CPU-kapacitet, istället för att enbart utgå från komprimeringsgraden. Zlib ger ofta den största utrymmesbesparingen vid måttlig beräkningsbelastning, medan lz4/lzo utmärker sig med låg latens. Jag använder främst LZMA eller bzip2 för arkiv eller tabeller som sällan ändras, eftersom CPU-belastningen är högre. Komprimeringsnivån (PAGE_COMPRESSION_LEVEL) styr förhållandet mellan hastighet och resursförbrukning, men med avtagande marginalnytta bortom de medelhöga nivåerna. En kort mätsekvens med den verkliga datamängden visar snabbt vilket alternativ som är bäst Nivå.
| Algoritm | Typisk ränta | CPU-kostnader | Lämplighet | Anteckningar |
|---|---|---|---|---|
| zlib | 40–60 % | Medium | Många OLTP-/rapporteringstabeller | Bra Balans från hastighet/fördröjning |
| lz4 | 30–50 % | Låg | Höga krav på genomströmning | Mycket snabb Dekompression |
| lzo | 30–50 % | Låg | Skrivintensiva arbetsuppgifter | Låg latens vid insättningar |
| lzma | 50–70 % | Hög | Arkiv/gamla uppgifter | För sällsynta Förändringar |
| bzip2 | 50–70 % | Hög | Selektiva historier | Långsamt, bra tittarsiffror |
Hålla koll på övervakning och nyckeltal
Jag mäter genomströmning, latens, CPU-utnyttjande och Buffertpool-Träfffrekvens, eftersom endast helhetsbilden visar den faktiska effekten. En minskning av I/O-volymerna vid oförändrad eller bättre latens indikerar att konfigurationen fungerar. Om CPU-belastningen stiger över en sund nivå kontrollerar jag algoritmen och nivån och byter vid behov till lz4. Dessutom beaktar jag storleken på redo-loggen och checkpoint-beteendet, eftersom båda dessa faktorer påverkar skrivprofilen. På lång sikt kan jag identifiera trender och proaktivt anpassa mig till förändrade Arbetsbelastning reagera.
Planera säkerhetskopiering och underhåll på ett ordnat sätt
Fullständiga och inkrementella filsäkerhetskopieringar drar nytta av den lägre datamängd, eftersom färre byte kopieras, medan logiska dumpningar oftast behåller sin storlek. Jag testar återställningstiderna med verkliga data för att kunna väga den utvunna utrymmesbesparingen mot den praktiska återställningstiden. Jag dokumenterar ändringar i algoritmen eller nivån och kontrollerar kompatibiliteten mellan säkerhetskopieringsverktygen och den använda MariaDB-versionen. Dessutom validerar jag integriteten efter stora ALTER TABLE-operationer, särskilt när många tabeller har ställts om till sidkomprimering. På så sätt förblir Tid för omstart förutsägbar och säkerhetsstrategin tillförlitlig.
Att förstå filsystemet och lagringsnivån
För att sparsfiler ska fungera krävs det att filsystemet Hålslagning, vilket finns tillgängligt för ext4 och XFS och är vanligt förekommande i webbhotellsmiljöer. Jag tittar på monteringsalternativ och ködjup, eftersom de har stor inverkan på I/O-karaktäristiken. För ext4 kontrollerar jag till exempel commit-intervall och journal-lägen och tar hänsyn till hur garbage collection påverkar SSD/NVMe. En titt på lämpliga ext4-alternativ hjälper till att anpassa effekterna av sidkomprimering till filsystemets egenskaper. Så här använder jag den fysiska Förvaring effektivt och förhindrar biverkningar.
Praktisk guide för introduktion
Jag börjar med en testmiljö och kopierar representativa produktionsdata för att få fram de första mätvärdena för kvot, latens och Genomströmning för att uppnå detta. Därefter aktiverar jag först sidkomprimering för stora tabeller eller arkiv som främst används för läsning och som har få uppdateringar. Jag utvärderar resultaten utifrån tydliga nyckeltal och jämför dem med utgångsläget innan jag ställer om ytterligare tabeller. Tidig kommunikation med applikationsteamen förhindrar överraskningar under underhållsfönster och säkerställer tydliga förväntningar. Efter varje utvidgning justerar jag nivån och Algoritm tills minnesbesparingen och latensen ligger inom målintervallet.
Kombination med ytterligare optimeringar
Bra index minskar antalet lästa sidor, därför kontrollerar jag Indexomfattning och kardinaliteter regelbundet. Välformulerade frågor, lämpliga sammanfogningar och målinriktad användning av EXPLAIN minskar I/O och håller cacheträfffrekvensen hög. En tillräckligt stor buffertpool förhindrar onödiga inläsningar från disken och gör komprimeringsöverheaden i hotsetet praktiskt taget osynlig. På hårdvarusidan lönar sig SSD-enheter och NVMe tack vare höga IOPS-värden och låg latens, vilket förstärker fördelarna med sidkomprimering. Sammantaget spelar komprimeringen en viktig roll tillsammans med utformningen av frågor, indexering och Utbyggnad av lagringskapaciteten tillsammans och bildar på så sätt en smidig dataväg.
Kompatibilitet, versioner och begränsningar
Jag håller koll på vilka miljöer som stöder sidkomprimering och var gränserna går. På vanliga Linux-filsystem som ext4 och XFS fungerar ”hole-punching” stabilt. ZFS beter sig annorlunda: Eftersom ”punching” inte är tillgängligt på samma sätt där föredrar jag att använda inhemsk Aktivera ZFS-komprimering och avstå från sidkomprimering. I container-miljöer med OverlayFS monterar jag helst datakatalogen som en bind-mount från värddatorn, så att punching och glesa filer fungerar pålitligt. Dessutom kombinerar jag inte sidkomprimering med InnoDB-tabellkryptering på filnivå: krypteringen gör data i stort sett slumpmässiga för komprimeringsalgoritmerna och blockerar delvis även punching. Den som behöver båda delarna bör använda volym-/filsystemkryptering under InnoDB.
När det gäller InnoDB-sidstorleken (innodb_page_size) brukar jag hålla mig till 16K. Mindre sidstorlekar kan försvåra komprimeringen och öka administrationskostnaderna. Tillfälliga tabeller eller MEMORY-/arbetstabeller påverkas inte av sidkomprimering – vinsten uppstår endast i respektive .ibd-tabellutrymme.
Aktivering, avaktivering och ombyggnader utan överraskningar
En ändring med ALTER TABLE leder alltid till att tabellen byggs om. Därför planerar jag följande:
- Underhållsfönster med tydliga SLA:er och tillräckligt med lagringsutrymme för den tillfälliga kopian.
- Förhandsgranskning med EXPLAIN för ALTER för att se det förväntade förfarandet (INPLACE/COPY, LOCK-nivå).
- Valfri batchstrategi: först stora tabeller som sällan ändras, därefter medelstora, och till sist de mest aktiva tabellerna – om nödvändigt.
För att inaktivera funktionen går jag tillväga symmetriskt och anger PAGE_COMPRESSED=0. Därefter kör jag ett OPTIMIZE TABLE eller ett nytt ALTER-Rebuild, så att tabellutrymmet återigen skrivs utan luckor och den fysiska utrymmesanvändningen återspeglas på ett realistiskt sätt.
Massinläsningar, hot-updates och defragmentering
När det gäller stora datamängder laddar jag antingen direkt i komprimerat format om I/O-resurserna är begränsade, eller så påskyndar jag importen genom att ladda i okomprimerat format och därefter byta till PAGE_COMPRESSED med ALTER TABLE. Därefter tvingar ombyggnaden fram den optimala layouten med maximal hålstansningseffekt. För tabeller med mycket många in-place-uppdateringar planerar jag regelbundna omskrivningar (OPTIMIZE TABLE eller partitionsrollovers), eftersom komprimeringsfördelarna kan minska över tid på grund av upprepade ändringar. För BLOB/TEXT-kolumner använder jag ett modernt radformat (t.ex. DYNAMIC) så att stora off-page-data hanteras effektivt och sidgrannskapet inte växer i onödan.
Kontrollera och belägga effektiviteten
Jag kontrollerar om sidkomprimering fungerar med hjälp av enkla systemkommandon och MariaDB-vyer:
# Jämföra skenbar storlek med upptagna block
ls -ls --block-size=1 *.ibd
du -h --apparent-size *.ibd
du -h *.ibd
# Kontrollera omfattningen av fragmentering (punching) per fil
filefrag -v your_table.ibd | tail -n +1
# I MariaDB: Kontrollera tabellstatus och DDL-alternativ
SHOW TABLE STATUS LIKE 'log_entries'\G
SHOW CREATE TABLE log_entries\G
Den skenbara storleken (ls) motsvarar den logiska datavolymen, medan du visar de faktiskt upptagna blocken. En märkbar skillnad indikerar att ”hole-punching” fungerar. Jag korrelerar denna mätning med I/O-mått (läsningar/skrivningar per sekund, ködjup, latens) och CPU-utnyttjandet för att utvärdera den totala effekten.
Säkerhetskopieringsinformation: Säkerhetskopiera och återställa Sparse på rätt sätt
För att säkerhetskopiorna ska ta hänsyn till utrymmesbesparingen ser jag till att verktygen har stöd för sparsa filer. När jag kopierar fysiska filer använder jag lämpliga alternativ så att luckor inte „fylls i“:
# Kopiera med bevarande av glesa områden
cp --sparse=always source.ibd dest.ibd
rsync -S --progress source.ibd dest.ibd
tar --sparse -cvf backup.tar /var/lib/mysql/datadir
# Kontrollera om målet fortfarande är spars
du -h dest.ibd
ls -ls dest.ibd
Vid snapshot-säkerhetskopieringar (t.ex. på blockenhetsnivå) varierar besparingens betydelse beroende på leverantör. För logiska dumpningar (mysqldump, mariadb-dump) förändras exportstorleken knappt, men återställningstiderna minskar om den efterföljande återuppbyggnaden återaktiverar sidkomprimering och därmed minskar I/O-volymerna vid återuppbyggnaden.
Replikering, hög tillgänglighet och driftsättning i drift
Sidkomprimering fungerar transparent för replikering och binloggar, eftersom det är SQL-ändringarna som replikeras, inte de komprimerade sidorna. Jag föredrar att först rulla ut DDL-ändringar till replikerna och övervaka latens och I/O innan jag ställer om primärservern. Vid topologier med flera källor eller kaskadtopologier ser jag till att en lämplig algoritm (innodb_compression_algorithm) är inställd överallt, så att identiska DDL-kommandon ger samma beteende. För driftsättningar utan driftstopp kombinerar jag övergången med switchover-/failover-planer.
Avancerad inställning: I/O-profiler och kontrollpunkter
Eftersom komprimeringen påverkar antalet och storleken på de block som ska skrivas anpassar jag InnoDB:s I/O-parametrar efter den nya profilen. Ett realistiskt värde för innodb_io_capacity (och *_max) bidrar till att skapa rena kontrollpunkter utan plötsliga toppar i flushing-frekvensen. Jag kontrollerar om doublewrite-bufferten harmonierar med den nya skrivkaraktäristiken och övervakar förhållandet mellan smutsiga sidor och fsync-frekvensen. På enheter med hög parallellitet (NVMe) skalar jag skrivtrådarna och ködjupet för blockenheten så att den minskade datamängden leder till en verklig minskning av latensen.
Felsökning och vanliga hinder
- CPU-toppar efter aktivering: Byt algoritm till lz4/lzo eller sänk PAGE_COMPRESSION_LEVEL något, och öka storleken på hotsets i buffertpoolen.
- I/O minskar, men latensen varierar: Kontrollera checkpointing och andelen ”dirty pages”; för små redo-loggar leder till frekventa tömningar.
- Oväntat liten platsbesparing: Kontrollera datastrukturen (många binära/slumpmässiga fält), tvinga fram en ombyggnad, analysera BLOB/TEXT-mönster, byt vid behov till zlib.
- Ingen inverkan på filstorleken: Kontrollera om filsystemet stöder hole-punching, undvik containerlager, och gör inte en „sparse-kopia“ till en ”tät-kopia”.
- Populära tabeller: Använd sidkomprimering selektivt; undersök alternativ (komprimera endast arkiv- och loggtabeller).
Praktiska konfigurations exempel
För att få en bra start föredrar jag att hålla den globala konfigurationen kort och överskådlig:
[mysqld]
innodb_file_per_table=1
innodb_compression_algorithm=zlib # eller lz4/lzo beroende på profil
# Anpassa övriga I/O-parametrar efter plattformen
# innodb_io_capacity=...
# innodb_io_capacity_max=...
För varje tabell definierar jag komprimeringen explicit för att undvika oönskade bieffekter. Efter stora importoperationer eller många uppdateringar använder jag OPTIMIZE TABLE på ett målinriktat sätt för att omkalibrera luckor och minska den fragmentering som uppstått över tid.
Kortfattat sammanfattat
InnoDB Page Compression minskar minnesanvändningen märkbart och avlastar I/O till CPU:n utan att ändra buffertpoolen. Väl valda algoritmer som lz4 eller zlib ger i många arbetsbelastningar en besparing på 30–60 % och håller latensen inom acceptabla gränser. Avgörande är ett filsystem med hole-punching, innodb_file_per_table och en korrekt aktivering på tabellnivå. Den som utför tester med verkliga data, integrerar övervakning och finjusterar nivåer samt algoritmer uppnår varaktigt låga kostnader med tillförlitlig Prestanda. På så sätt sparar du utrymme, håller dina system snabba och skapar utrymme för växande datamängder.
