{"id":21263,"date":"2026-09-02T11:49:39","date_gmt":"2026-09-02T09:49:39","guid":{"rendered":"https:\/\/webhosting.de\/mariadb-page-compression-speicherplatz-optimierung-datenbank\/"},"modified":"2026-09-02T11:49:39","modified_gmt":"2026-09-02T09:49:39","slug":"mariadb-%d1%81%d0%b6%d0%b0%d1%82%d0%b8%d0%b5-%d1%81%d1%82%d1%80%d0%b0%d0%bd%d0%b8%d1%86-%d0%be%d0%bf%d1%82%d0%b8%d0%bc%d0%b8%d0%b7%d0%b0%d1%86%d0%b8%d1%8f-%d0%b4%d0%b8%d1%81%d0%ba%d0%be%d0%b2%d0%be","status":"publish","type":"post","link":"https:\/\/webhosting.de\/ru\/mariadb-page-compression-speicherplatz-optimierung-datenbank\/","title":{"rendered":"\u0421\u0436\u0430\u0442\u0438\u0435 \u0441\u0442\u0440\u0430\u043d\u0438\u0446 \u0432 MariaDB: \u044d\u043a\u043e\u043d\u043e\u043c\u0438\u044f \u043c\u0435\u0441\u0442\u0430 \u043d\u0430 \u0434\u0438\u0441\u043a\u0435 \u0441 \u043c\u0438\u043d\u0438\u043c\u0430\u043b\u044c\u043d\u044b\u043c \u0441\u043d\u0438\u0436\u0435\u043d\u0438\u0435\u043c \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438"},"content":{"rendered":"<p><strong>MariaDB Page<\/strong> Compression reduziert den physischen Speicherbedarf, indem InnoDB-Seiten vor dem Schreiben auf Datentr\u00e4ger komprimiert werden und so I\/O-Mengen sp\u00fcrbar sinken. Ich zeige, wie Sie Speicher sparen und die Latenz gering halten, welche Voraussetzungen gelten und welche Einstellungen in der Praxis am meisten bewirken.<\/p>\n\n<h2>Zentrale Punkte<\/h2>\n<p>Diese kompakten Stichpunkte f\u00fchren in die wichtigsten Aspekte ein.<\/p>\n<ul>\n  <li><strong>Seitenweise<\/strong> Kompression senkt Platzbedarf und I\/O.<\/li>\n  <li><strong>Unkomprimierter<\/strong> Buffer-Pool begrenzt CPU-Last im RAM.<\/li>\n  <li><strong>Flexible<\/strong> Aktivierung pro Tabelle mit PAGE_COMPRESSED.<\/li>\n  <li><strong>Dateisystem<\/strong>-Support f\u00fcr Sparse\/Hole Punching ist Pflicht.<\/li>\n  <li><strong>Algorithmuswahl<\/strong> steuert Rate, Latenz und CPU-Kosten.<\/li>\n<\/ul>\n\n<h2>Wie InnoDB Page Compression technisch arbeitet<\/h2>\n\n<p>Ich komprimiere jede InnoDB-Seite kurz bevor sie auf die Platte gelangt, sodass der Tablespace nur die tats\u00e4chlich reduzierten Bytes belegt und das Dateisystem freie Bereiche als Sparse markiert. Im <strong>Buffer-Pool<\/strong> halte ich Seiten weiterhin unkomprimiert, was die CPU-Kosten im Arbeitsspeicher gering h\u00e4lt und h\u00e4ufige Lesezugriffe schnell bleiben. Standardm\u00e4\u00dfig besitzen InnoDB-Seiten 16K, doch die gespeicherten Bl\u00f6cke fallen nach der Kompression variabel kleiner aus, was besonders bei Text- oder JSON-Feldern viel Platz einspart. Beim Lesen entpacke ich die Seite direkt nach dem Laden ins RAM, also genau an der I\/O-Grenze, wo die Einsparung bei der \u00dcbertragung am meisten z\u00e4hlt. So verlagere ich Last von <strong>I\/O<\/strong> zur CPU, aber nur an den Stellen, an denen sie vertretbar ist.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb-speicherplatz-7463.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Page Compression vs. klassische InnoDB-Tabellenkompression<\/h2>\n\n<p>Die klassische Kompression setzt auf ROW_FORMAT=COMPRESSED plus KEY_BLOCK_SIZE, was ein fixes komprimiertes Seitenformat erzeugt und beim Schreiben oder Aktualisieren eine zus\u00e4tzliche Entscheidungslast bringt. Ich bevorzuge die <strong>Page<\/strong> Compression, weil sie flexibel bleibt: Gelingt eine Kompression nicht, kann InnoDB die Seite unkomprimiert ablegen, ohne das gesamte Dateiformat zu \u00e4ndern. Der Buffer-Pool arbeitet weiterhin mit unkomprimierten 16K-Pages, was Cache-Treffer schnell macht und die CPU-Pfade einfach h\u00e4lt. Bei typischen OLTP-Workloads mit vielen Inserts und moderaten Updates liefert Page Compression eine bessere Balance aus Platzersparnis und Latenz. Im Ergebnis erhalte ich oft den sp\u00fcrbaren I\/O-Vorteil, ohne einen hohen Overhead bei jedem <strong>Update<\/strong> zu riskieren.<\/p>\n\n<h2>Voraussetzungen und Grundkonfiguration<\/h2>\n\n<p>F\u00fcr Page Compression setze ich InnoDB voraus und aktiviere <strong>innodb_file_per_table<\/strong>, damit jede Tabelle ihren eigenen Tablespace nutzt. Entscheidend ist das Dateisystem: Es muss Sparse-Dateien und Hole-Punching beherrschen, was bei ext4 und XFS gegeben ist und in modernen Cloud-Volumes in der Regel vorhanden ist. F\u00fcr die Wahl des Algorithmus steuere ich innodb_compression_algorithm, typischerweise zlib, lz4 oder lzo, je nach gew\u00fcnschter Rate und CPU-Profil. Wer die Storage-Schicht abw\u00e4gt, profitiert von einem kompakten <a href=\"https:\/\/webhosting.de\/ext4-xfs-zfs-hosting-performance-vergleich-storage\/\">Dateisystem-Vergleich<\/a> und ber\u00fccksichtigt dabei auch Treiber- und Volume-Optionen. So entsteht eine <strong>Konfiguration<\/strong>, die Platz spart, I\/O reduziert und verl\u00e4sslich arbeitet.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb_page_compression_6743.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Aktivierung auf Tabellenebene<\/h2>\n\n<p>Ich schalte Page Compression pro Tabelle scharf, afterdem die globalen Variablen stimmen, damit ich gezielt genau die Datens\u00e4tze adressiere, die den gr\u00f6\u00dftm\u00f6glichen Nutzen bringen. F\u00fcr neue Tabellen setze ich die Optionen direkt in der DDL, bei bestehenden Tabellen erledigt ein ALTER TABLE die Umstellung durch Neuschreiben. Die Kompressionsstufe definiere ich mit PAGE_COMPRESSION_LEVEL, das Verhalten h\u00e4ngt vom verwendeten <strong>Algorithmus<\/strong> ab. Weil die Umstellung Zeit kostet, plane ich Wartungsfenster ein und pr\u00fcfe den Platzbedarf mit und ohne Kompression anhand realer Datenausschnitte. So kontrolliere ich <strong>Aufwand<\/strong> und Ergebnis ohne \u00dcberraschungen.<\/p>\n<pre><code>CREATE TABLE log_entries (\n    id BIGINT UNSIGNED PRIMARY KEY,\n    created_at DATETIME NOT NULL,\n    level VARCHAR(20),\n    message TEXT\n) ENGINE=InnoDB\n  PAGE_COMPRESSED=1\n  PAGE_COMPRESSION_LEVEL=6;\n\nALTER TABLE log_entries\n  ENGINE=InnoDB,\n  PAGE_COMPRESSED=1;\n<\/code><\/pre>\n\n<h2>Speicherersparnis in der Praxis<\/h2>\n\n<p>Je homogener und textlastiger die Daten, desto besser wirkt die <strong>Kompression<\/strong>; Log- und Reporting-Tabellen liefern meist deutliche Effekte. In typischen Workloads sehe ich oft 40\u201360 % weniger belegten Speicher mit zlib, w\u00e4hrend lz4 viele F\u00e4lle mit 30\u201350 % bedient und daf\u00fcr mehr Durchsatz \u00fcbrig l\u00e4sst. Stark verteilte Bin\u00e4rdaten bringen weniger, doch auch dort reduzieren sich I\/O-Mengen und Kosten oft merkbar. Ich teste immer mit Produktionsschnappsch\u00fcssen auf Staging, um aussagekr\u00e4ftige Quoten zu gewinnen und Latency-Spitzen zu erkennen. Das Ergebnis: weniger Daten auf dem Datentr\u00e4ger, k\u00fcrzere Transferzeiten, bessere <strong>Skalierung<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb-page-compression-9832.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Performance: I\/O vs. CPU richtig bewerten<\/h2>\n\n<p>Ich pr\u00fcfe zuerst, ob der Engpass auf dem Datentr\u00e4ger oder auf der <strong>CPU<\/strong> liegt, denn davon h\u00e4ngt die Wahl der Kompressionsmethode ab. In I\/O-limitierten Umgebungen sinken Lese- und Schreibmengen deutlich, sodass die effektive Leistung steigt, oft mit nur 5\u201310 % Zusatzlast gegen\u00fcber unkomprimierten Tabellen bei schnellen Algorithmen. CPU-limitierte Systeme profitieren von lz4 oder lzo, die sehr schnell arbeiten und nur etwas geringere Raten erreichen. Zus\u00e4tzlich beachte ich den <a href=\"https:\/\/webhosting.de\/innodb-doublewrite-buffer-sicherheit-performance-tuning-focus\/\">Doublewrite-Buffer<\/a>, weil er das Schreibverhalten beeinflusst und zusammen mit Page Compression die I\/O-Charakteristik formt. Da der Buffer-Pool unkomprimiert bleibt, wirken sich h\u00e4ufige Cache-Treffer kaum auf die <strong>Latenz<\/strong> aus.<\/p>\n\n<h2>Algorithmuswahl und Kompressionslevel<\/h2>\n\n<p>Ich entscheide die <strong>Algorithmus<\/strong>-Frage anhand von Datenmustern, Lese-\/Schreibrate und CPU-Spielraum, statt mich nur an der Kompressionsquote zu orientieren. Zlib liefert oft die h\u00f6chste Platzersparnis bei moderater Rechenarbeit, w\u00e4hrend lz4\/lzo mit geringer Latenz gl\u00e4nzen. LZMA oder bzip2 nutze ich vor allem f\u00fcr Archive oder selten ver\u00e4nderte Tabellen, da die CPU-Kosten h\u00f6her sind. Die Kompressionsstufe (PAGE_COMPRESSION_LEVEL) regelt das Verh\u00e4ltnis zwischen Rate und Aufwand, jedoch mit abnehmendem Grenznutzen jenseits mittlerer Stufen. Eine kurze Messreihe mit dem echten Datensatz findet schnell das beste <strong>Niveau<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Algorithmus<\/th>\n      <th>Typische Rate<\/th>\n      <th>CPU-Kosten<\/th>\n      <th>Eignung<\/th>\n      <th>Hinweise<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>zlib<\/td>\n      <td>40\u201360 %<\/td>\n      <td>Mittel<\/td>\n      <td>Viele OLTP\/Reporting-Tabellen<\/td>\n      <td>Gute <strong>Balance<\/strong> aus Rate\/Latenz<\/td>\n    <\/tr>\n    <tr>\n      <td>lz4<\/td>\n      <td>30\u201350 %<\/td>\n      <td>Niedrig<\/td>\n      <td>Hohe Durchsatzanforderungen<\/td>\n      <td>Sehr schnelle <strong>Dekompression<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>lzo<\/td>\n      <td>30\u201350 %<\/td>\n      <td>Niedrig<\/td>\n      <td>Schreibintensive Workloads<\/td>\n      <td>Geringe Latenz bei Inserts<\/td>\n    <\/tr>\n    <tr>\n      <td>lzma<\/td>\n      <td>50\u201370 %<\/td>\n      <td>Hoch<\/td>\n      <td>Archive\/kalte Daten<\/td>\n      <td>F\u00fcr seltene <strong>\u00c4nderungen<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>bzip2<\/td>\n      <td>50\u201370 %<\/td>\n      <td>Hoch<\/td>\n      <td>Selektive Historien<\/td>\n      <td>Langsam, gute Quote<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/speicherplatzersparnis4267.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitoring und Metriken im Blick behalten<\/h2>\n\n<p>Ich messe Durchsatz, Latenz, CPU-Auslastung und <strong>Buffer-Pool<\/strong>-Hitrate, weil nur die Gesamtsicht den tats\u00e4chlichen Effekt zeigt. Ein Absinken der I\/O-Mengen bei gleichbleibender oder besserer Latenz signalisiert einen Treffer in der Konfiguration. Steigt die CPU-Auslastung \u00fcber ein gesundes Niveau, kontrolliere ich Algorithmus und Level und setze ggf. auf lz4 um. Zus\u00e4tzlich beachte ich die Gr\u00f6\u00dfe des Redo-Logs und das Checkpoint-Verhalten, da beides das Schreibprofil mitpr\u00e4gt. Langfristig erkenne ich Trends und kann proaktiv auf ge\u00e4nderte <strong>Workloads<\/strong> reagieren.<\/p>\n\n<h2>Backups und Wartung sauber planen<\/h2>\n\n<p>Voll- und inkrementelle Dateisicherungen profitieren von der geringeren <strong>Datenmenge<\/strong>, weil weniger Bytes kopiert werden, w\u00e4hrend logische Dumps ihre Gr\u00f6\u00dfe meist behalten. Ich teste Restore-Zeiten mit realen Daten, damit ich die gewonnene Platzersparnis gegen die praktische Wiederherstellungsdauer abw\u00e4gen kann. \u00c4nderungen am Algorithmus oder Level dokumentiere ich und pr\u00fcfe Kompatibilit\u00e4t der Backup-Tools mit der eingesetzten MariaDB-Version. Au\u00dferdem validiere ich die Integrit\u00e4t nach gro\u00dfen ALTER TABLE-Operationen, gerade wenn viele Tabellen auf Page Compression umgestellt wurden. So bleibt die <strong>Wiederanlaufzeit<\/strong> vorhersagbar und die Sicherungsstrategie verl\u00e4sslich.<\/p>\n\n<h2>Dateisystem und Storage-Ebene verstehen<\/h2>\n\n<p>Damit Sparse-Dateien greifen, ben\u00f6tigt das Dateisystem <strong>Hole-Punching<\/strong>, was bei ext4 und XFS verf\u00fcgbar ist und in Hosting-Setups weit verbreitet ist. Ich achte auf Mount-Optionen und Queue-Depth, da sie die I\/O-Kennlinien stark beeinflussen. F\u00fcr ext4 \u00fcberpr\u00fcfe ich etwa Commit-Intervalle und Journal-Modi und ber\u00fccksichtige, wie Garbage-Collection auf SSD\/NVMe wirkt. Ein Blick auf passende <a href=\"https:\/\/webhosting.de\/ext4-mount-optionen-hosting-server-tuning-performance-io\/\">ext4-Optionen<\/a> hilft, die Page-Compression-Effekte mit den Eigenschaften des Dateisystems abzustimmen. So nutze ich den physischen <strong>Storage<\/strong> effizient und verhindere Nebenwirkungen.<\/p>\n\n<h2>Praxisleitfaden f\u00fcr die Einf\u00fchrung<\/h2>\n\n<p>Ich starte mit einer Testumgebung und kopiere repr\u00e4sentative Produktionsdaten, um erste Messwerte f\u00fcr Quote, Latenz und <strong>Durchsatz<\/strong> zu erhalten. Danach aktiviere ich Page Compression zun\u00e4chst bei gro\u00dfen, \u00fcberwiegend lesenden Tabellen oder Archiven mit wenigen Updates. Die Ergebnisse bewerte ich anhand klarer Kennzahlen und vergleiche sie mit dem Ausgangszustand, bevor ich weitere Tabellen umstelle. Fr\u00fchzeitige Kommunikation mit Applikationsteams verhindert \u00dcberraschungen bei Wartungsfenstern und sorgt f\u00fcr klare Erwartungen. Nach jeder Ausweitung passe ich Level und <strong>Algorithmus<\/strong> an, bis Speicherersparnis und Latenz im Zielkorridor liegen.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb-compression-6743.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kombination mit weiteren Optimierungen<\/h2>\n\n<p>Gute Indizes reduzieren die Zahl gelesener Seiten, daher pr\u00fcfe ich <strong>Indexabdeckung<\/strong> und Kardinalit\u00e4ten regelm\u00e4\u00dfig. Sauber formulierte Abfragen, passende Joins und der gezielte Einsatz von EXPLAIN senken I\/O und halten die Cache-Trefferquote hoch. Eine ausreichend gro\u00dfe Buffer-Pool-Gr\u00f6\u00dfe verhindert unn\u00f6tige Ladevorg\u00e4nge von Disk und macht den Kompressions-Overhead im Hotset praktisch unsichtbar. Auf der Hardware-Seite zahlen sich SSDs und NVMe durch hohe IOPS und geringe Latenz aus, was die Vorteile der Page Compression verst\u00e4rkt. In Summe spielt die Kompression mit Query-Design, Indexarbeit und <strong>Speicherausbau<\/strong> zusammen und formt so einen schlanken Datenpfad.<\/p>\n\n<h2>Kompatibilit\u00e4t, Versionen und Grenzen<\/h2>\n<p>Ich halte im Blick, welche Umgebung Page Compression unterst\u00fctzt und wo Grenzen liegen. Auf verbreiteten Linux-Dateisystemen wie ext4 und XFS funktioniert Hole-Punching stabil. ZFS verh\u00e4lt sich anders: Da Punching dort nicht gleichwertig verf\u00fcgbar ist, setze ich auf ZFS eher die <em>native<\/em> ZFS-Kompression ein und verzichte auf Page Compression. In Container-Setups mit OverlayFS binde ich das Datenverzeichnis vorzugsweise als Bind-Mount vom Host ein, damit Punching und Sparse-Dateien zuverl\u00e4ssig greifen. Au\u00dferdem kombiniere ich Page Compression nicht mit InnoDB-Tabellenverschl\u00fcsselung auf Dateiebene: Verschl\u00fcsselung macht die Daten f\u00fcr Kompressionsalgorithmen weitgehend zuf\u00e4llig und blockiert teils auch das Punching. Wer beides ben\u00f6tigt, setzt auf Volume-\/Filesystem-Verschl\u00fcsselung unterhalb von InnoDB.<\/p>\n<p>Bei der InnoDB-Seitengr\u00f6\u00dfe (innodb_page_size) bleibe ich meist bei 16K. Kleinere Seitengr\u00f6\u00dfen k\u00f6nnen die Kompression erschweren und die Verwaltungs-Overheads erh\u00f6hen. Tempor\u00e4re Tabellen oder MEMORY\/Arbeitstabellen ver\u00e4ndern sich durch Page Compression nicht \u2013 der Gewinn entsteht nur im jeweiligen .ibd-Tablespace.<\/p>\n\n<h2>Aktivierung, Deaktivierung und Rebuilds ohne \u00dcberraschungen<\/h2>\n<p>Die Umstellung per ALTER TABLE erzeugt immer einen Rebuild der Tabelle. Ich plane daher:<\/p>\n<ul>\n  <li>Wartungsfenster mit klaren SLAs und ausreichendem Speicherplatz f\u00fcr die tempor\u00e4re Kopie.<\/li>\n  <li>Vorabpr\u00fcfung mit EXPLAIN f\u00fcr ALTER, um das erwartete Vorgehen (INPLACE\/COPY, LOCK-Level) zu sehen.<\/li>\n  <li>Optionale Batching-Strategie: erst gro\u00dfe, selten ver\u00e4nderte Tabellen, danach mittlere, am Ende die hei\u00dfen Tabellen \u2013 wenn \u00fcberhaupt.<\/li>\n<\/ul>\n<p>Zum Abschalten gehe ich symmetrisch vor und setze PAGE_COMPRESSED=0. Anschlie\u00dfend f\u00fchre ich ein OPTIMIZE TABLE oder einen erneuten ALTER-Rebuild aus, damit der Tablespace wieder ohne L\u00f6cher geschrieben wird und der physische Platzverbrauch realistisch abgebildet ist.<\/p>\n\n<h2>Bulk Loads, Hot-Updates und Defragmentierung<\/h2>\n<p>F\u00fcr Massendaten lade ich entweder direkt komprimiert, wenn I\/O knapp ist, oder ich beschleunige den Import, indem ich unkomprimiert lade und danach mit ALTER TABLE auf PAGE_COMPRESSED umstelle. Anschlie\u00dfend erzwingt der Rebuild das optimale Layout mit maximaler Loch-Punching-Wirkung. Bei Tabellen mit sehr vielen In-Place-Updates plane ich regelm\u00e4\u00dfige Rewrites (OPTIMIZE TABLE oder Partition-Rollovers), weil sich durch wiederholte \u00c4nderungen die Kompressionsvorteile \u00fcber die Zeit mindern k\u00f6nnen. F\u00fcr BLOB\/TEXT-Spalten setze ich auf ein zeitgem\u00e4\u00dfes Zeilenformat (z. B. DYNAMIC), damit gro\u00dfe Off-Page-Daten effizient gehandhabt werden und die Seitennachbarschaft nicht unn\u00f6tig w\u00e4chst.<\/p>\n\n<h2>Wirksamkeit pr\u00fcfen und belegen<\/h2>\n<p>Ob Page Compression greift, verifiziere ich mit einfachen Systemkommandos und MariaDB-Sichten:<\/p>\n<pre><code># Apparente Gr\u00f6\u00dfe vs. belegte Bl\u00f6cke vergleichen\nls -ls --block-size=1 *.ibd\ndu -h --apparent-size *.ibd\ndu -h *.ibd\n\n# Ausma\u00df der Lochbildung (Punching) pro Datei pr\u00fcfen\nfilefrag -v your_table.ibd | tail -n +1\n\n# In MariaDB: Tabellenstatus und DDL-Optionen pr\u00fcfen\nSHOW TABLE STATUS LIKE 'log_entries'\\G\nSHOW CREATE TABLE log_entries\\G\n<\/code><\/pre>\n<p>Die apparente Gr\u00f6\u00dfe (ls) bleibt beim logischen Datenvolumen, w\u00e4hrend du die tats\u00e4chlich belegten Bl\u00f6cke zeigt. Eine sp\u00fcrbare Differenz signalisiert funktionierendes Hole-Punching. Ich korreliere diese Messung mit I\/O-Metriken (Reads\/Writes pro Sekunde, Warteschlangentiefe, Latenz) und der CPU-Auslastung, um den Gesamteffekt zu bewerten.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb_effizient_4821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Backup-Details: Sparse korrekt sichern und wiederherstellen<\/h2>\n<p>Damit Backups die Platzersparnis respektieren, achte ich auf Sparse-Unterst\u00fctzung in den Werkzeugen. Beim Kopieren physischer Dateien nutze ich passende Schalter, damit L\u00f6cher nicht \u201egef\u00fcllt\u201c werden:<\/p>\n<pre><code># Kopieren mit Erhalt von Sparse-Bereichen\ncp --sparse=always source.ibd dest.ibd\nrsync -S --progress source.ibd dest.ibd\ntar --sparse -cvf backup.tar \/var\/lib\/mysql\/datadir\n\n# Pr\u00fcfen, ob das Ziel weiterhin Sparse ist\ndu -h dest.ibd\nls -ls dest.ibd\n<\/code><\/pre>\n<p>Bei Snapshot-Backups (z. B. auf Block-Device-Ebene) ist die Ersparnis je nach Anbieter unterschiedlich relevant. F\u00fcr logische Dumps (mysqldump, mariadb-dump) \u00e4ndert sich die Exportgr\u00f6\u00dfe kaum, jedoch sinken Restore-Zeiten, wenn der anschlie\u00dfende Rebuild wieder Page Compression aktiviert und damit die I\/O-Mengen beim Neuaufbau reduziert.<\/p>\n\n<h2>Replikation, HA und Rollouts im Betrieb<\/h2>\n<p>Page Compression wirkt transparent f\u00fcr Replikation und Binlogs, denn repliziert werden SQL-\u00c4nderungen, nicht die komprimierten Seiten. Ich rolle DDL-\u00c4nderungen bevorzugt zuerst auf Replikas aus und beobachte Latenz und I\/O, bevor ich den Prim\u00e4rserver umstelle. Bei Multi-Source- oder Kaskaden-Topologien achte ich darauf, dass \u00fcberall ein passender Algorithmus (innodb_compression_algorithm) gesetzt ist, damit identische DDL das gleiche Verhalten erzielt. F\u00fcr Zero-Downtime-Rollouts kombiniere ich die Umstellung mit Switchover\/Failover-Pl\u00e4nen.<\/p>\n\n<h2>Tieferes Tuning: I\/O-Profile und Checkpoints<\/h2>\n<p>Weil Kompression die Anzahl und Gr\u00f6\u00dfe der zu schreibenden Bl\u00f6cke ver\u00e4ndert, stimme ich InnoDBs I\/O-Parameter auf das neue Profil ab. Eine realistische innodb_io_capacity (und *_max) hilft, saubere Checkpoints zu erzeugen, ohne pl\u00f6tzliche Flush-Spitzen. Ich pr\u00fcfe, ob der Doublewrite-Buffer mit der neuen Schreibcharakteristik harmoniert, und \u00fcberwache das Verh\u00e4ltnis aus dirty pages und fsync-Rate. Auf Ger\u00e4ten mit hoher Parallelit\u00e4t (NVMe) skaliere ich die Write-Threads und die Queue-Tiefe des Blockger\u00e4ts, damit die geringere Datenmenge als echte Latenzreduktion ankommt.<\/p>\n\n<h2>Problembehebung und typische Stolpersteine<\/h2>\n<ul>\n  <li><strong>CPU-Spitzen nach Aktivierung:<\/strong> Algorithmus auf lz4\/lzo wechseln oder PAGE_COMPRESSION_LEVEL moderat senken, Hotsets im Buffer-Pool vergr\u00f6\u00dfern.<\/li>\n  <li><strong>I\/O sinkt, aber Latenz schwankt:<\/strong> Checkpointing und Dirty-Page-Quote pr\u00fcfen; zu kleine Redo-Logs f\u00fchren zu h\u00e4ufigen Flushes.<\/li>\n  <li><strong>Unerwartet geringe Platzersparnis:<\/strong> Datenstruktur pr\u00fcfen (viele bin\u00e4re\/zuf\u00e4llige Felder), Rebuild erzwingen, BLOB\/TEXT-Muster analysieren, ggf. auf zlib wechseln.<\/li>\n  <li><strong>Kein Effekt auf Dateigr\u00f6\u00dfe:<\/strong> Hole-Punching-Unterst\u00fctzung des Dateisystems kontrollieren, Container-Layer vermeiden, Sparse-Kopie nicht \u201eentsparsifizieren\u201c.<\/li>\n  <li><strong>Hei\u00df beschriebene Tabellen:<\/strong> Page Compression selektiv einsetzen; Alternativen pr\u00fcfen (nur Archiv-\/Log-Tabellen komprimieren).<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb-page-compression-9832.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Praxisnahe Konfigurationsbeispiele<\/h2>\n<p>F\u00fcr einen sauberen Start halte ich die globale Konfiguration knapp und steuerbar:<\/p>\n<pre><code>[mysqld]\ninnodb_file_per_table=1\ninnodb_compression_algorithm=zlib   # oder lz4\/lzo je nach Profil\n# weitere I\/O-Parameter passend zur Plattform anpassen\n# innodb_io_capacity=...\n# innodb_io_capacity_max=...\n<\/code><\/pre>\n<p>Pro Tabelle definiere ich die Kompression explizit, um keine ungewollten Seiteneffekte zu erzeugen. Nach gro\u00dfen Imports oder vielen Updates setze ich gezielt OPTIMIZE TABLE ein, um L\u00f6cher neu zu kalibrieren und das \u00fcber die Zeit entstandene Fragment zu reduzieren.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb-compression-6743.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kurz zusammengefasst<\/h2>\n\n<p>InnoDB Page Compression reduziert den Speicherverbrauch sp\u00fcrbar und verschiebt Last von <strong>I\/O<\/strong> zur CPU, ohne den Buffer-Pool zu ver\u00e4ndern. Gut gew\u00e4hlte Algorithmen wie lz4 oder zlib liefern in vielen Workloads 30\u201360 % Einsparung und bleiben bei der Latenz im gr\u00fcnen Bereich. Entscheidend sind ein Dateisystem mit Hole-Punching, innodb_file_per_table und eine saubere Aktivierung auf Tabellenebene. Wer Tests mit echten Daten f\u00e4hrt, Monitoring einbindet und Level sowie Algorithmus feinjustiert, erreicht dauerhaft geringe Kosten bei verl\u00e4sslicher <strong>Performance<\/strong>. So sparen Sie Platz, halten Ihre Systeme flink und gewinnen Reserven f\u00fcr wachsende Datens\u00e4tze.<\/p>","protected":false},"excerpt":{"rendered":"<p>\u0423\u0437\u043d\u0430\u0439\u0442\u0435, \u043a\u0430\u043a \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e \u0441\u0436\u0430\u0442\u0438\u044f \u0441\u0442\u0440\u0430\u043d\u0438\u0446 MariaDB \u0443\u043c\u0435\u043d\u044c\u0448\u0438\u0442\u044c \u043e\u0431\u044a\u0435\u043c \u043f\u0430\u043c\u044f\u0442\u0438, \u0437\u0430\u043d\u0438\u043c\u0430\u0435\u043c\u044b\u0439 \u0431\u043e\u043b\u044c\u0448\u0438\u043c\u0438 \u0442\u0430\u0431\u043b\u0438\u0446\u0430\u043c\u0438 InnoDB, \u0438 \u043e\u043f\u0442\u0438\u043c\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u0435 \u0434\u0430\u043d\u043d\u044b\u0445 \u0432 \u0431\u0430\u0437\u0435 \u0434\u0430\u043d\u043d\u044b\u0445 \u2014 \u0431\u0435\u0437 \u0437\u043d\u0430\u0447\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0439 \u043f\u043e\u0442\u0435\u0440\u0438 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438.<\/p>","protected":false},"author":1,"featured_media":21256,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-21263","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenbanken-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"111","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"MariaDB Page","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"21256","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/ru\/wp-json\/wp\/v2\/posts\/21263","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/ru\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/ru\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/ru\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/ru\/wp-json\/wp\/v2\/comments?post=21263"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/ru\/wp-json\/wp\/v2\/posts\/21263\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/ru\/wp-json\/wp\/v2\/media\/21256"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/ru\/wp-json\/wp\/v2\/media?parent=21263"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/ru\/wp-json\/wp\/v2\/categories?post=21263"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/ru\/wp-json\/wp\/v2\/tags?post=21263"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}