Geen cache-versie.
Caching uitgeschakeld. Standaardinstelling voor deze pagina:ingeschakeld (code DEF204)Als het scherm te langzaam is, kunt u de gebruikersmodus uitschakelen om de cacheversie te bekijken.
Rechercher dans le manuel MySQL
15.9.1.1 Overview of Table Compression
Because processors and cache memories have increased in speed more than disk storage devices, many workloads are disk-bound. Data compression enables smaller database size, reduced I/O, and improved throughput, at the small cost of increased CPU utilization. Compression is especially valuable for read-intensive applications, on systems with enough RAM to keep frequently used data in memory.
An InnoDB table created with
ROW_FORMAT=COMPRESSED can use a smaller
page size on disk than the
configured innodb_page_size
value. Smaller pages require less I/O to read from and write to
disk, which is especially valuable for
SSD devices.
The compressed page size is specified through the
CREATE TABLE or
ALTER TABLE
KEY_BLOCK_SIZE parameter. The different page
size requires that the table be placed in a
file-per-table
tablespace or general
tablespace rather than in the
system tablespace,
as the system tablespace cannot store compressed tables. For
more information, see
Section 15.6.3.2, “File-Per-Table Tablespaces”, and
Section 15.6.3.3, “General Tablespaces”.
The level of compression is the same regardless of the
KEY_BLOCK_SIZE value. As you specify smaller
values for KEY_BLOCK_SIZE, you get the I/O
benefits of increasingly smaller pages. But if you specify a
value that is too small, there is additional overhead to
reorganize the pages when data values cannot be compressed
enough to fit multiple rows in each page. There is a hard limit
on how small KEY_BLOCK_SIZE can be for a
table, based on the lengths of the key columns for each of its
indexes. Specify a value that is too small, and the
CREATE TABLE or
ALTER TABLE statement fails.
In the buffer pool, the compressed data is held in small pages,
with a page size based on the KEY_BLOCK_SIZE
value. For extracting or updating the column values, MySQL also
creates an uncompressed page in the buffer pool with the
uncompressed data. Within the buffer pool, any updates to the
uncompressed page are also re-written back to the equivalent
compressed page. You might need to size your buffer pool to
accommodate the additional data of both compressed and
uncompressed pages, although the uncompressed pages are
evicted from the buffer
pool when space is needed, and then uncompressed again on the
next access.
Nederlandse vertaling
U hebt gevraagd om deze site in het Nederlands te bezoeken. Voor nu wordt alleen de interface vertaald, maar nog niet alle inhoud.Als je me wilt helpen met vertalingen, is je bijdrage welkom. Het enige dat u hoeft te doen, is u op de site registreren en mij een bericht sturen waarin u wordt gevraagd om u toe te voegen aan de groep vertalers, zodat u de gewenste pagina's kunt vertalen. Een link onderaan elke vertaalde pagina geeft aan dat u de vertaler bent en heeft een link naar uw profiel.
Bij voorbaat dank.
Document heeft de 26/06/2006 gemaakt, de laatste keer de 26/10/2018 gewijzigd
Bron van het afgedrukte document:https://www.gaudry.be/nl/mysql-rf-innodb-compression-background.html
De infobrol is een persoonlijke site waarvan de inhoud uitsluitend mijn verantwoordelijkheid is. De tekst is beschikbaar onder CreativeCommons-licentie (BY-NC-SA). Meer info op de gebruiksvoorwaarden en de auteur.
Referenties
Deze verwijzingen en links verwijzen naar documenten die geraadpleegd zijn tijdens het schrijven van deze pagina, of die aanvullende informatie kunnen geven, maar de auteurs van deze bronnen kunnen niet verantwoordelijk worden gehouden voor de inhoud van deze pagina.
De auteur Deze site is als enige verantwoordelijk voor de manier waarop de verschillende concepten, en de vrijheden die met de referentiewerken worden genomen, hier worden gepresenteerd. Vergeet niet dat u meerdere broninformatie moet doorgeven om het risico op fouten te verkleinen.
