Waarom is de AVG-rijlengte 4 keer zo groot als verwacht?

Er zijn veel redenen waarom de gemiddelde rijgrootte hoog is.

• Het is een benadering. (Ik heb ontdekt dat het meestal 2x-3x hoog is.) In een extreem geval -- één rij in de tabel -- zal het 16384 bytes per rij claimen. Dat is één InnoDB-blok. Het aantal rijen in de tabel is geschat . De schijfruimte die voor de rijen wordt gebruikt, is exact, maar zie de overheadkosten hieronder. De gemiddelde rijgrootte is het quotiënt van die twee.

• Overhead per kolom -- 1 of 2 bytes

• Overhead per rij -- 20-30 bytes -- voor het afhandelen van transacties, het vinden van rijen in een blok, enz.

• Overhead per blok -- een aantal bytes per blok van 16 KB

• Overhead voor thrashing in een BTree -- min is ongeveer 1/16 van een blok, max is ongeveer de helft van het blok, het gemiddelde is ongeveer 30% na veel verwijderingen en/of willekeurige invoegingen.

• Overhead voor het vooraf toewijzen van stukken schijfruimte (1 MB? 8 MB?)

• Naarmate een tafel groeit doordat hij niet in één blok past, verschuift het lay-outalgoritme en neemt het percentage overhead tijdelijk toe.

• Verwijderde rijen geven hun ruimte niet terug aan het besturingssysteem, dus de bestandsgrootte blijft constant, waardoor de schijnbare groter wordt rijgrootte.

• Als u geen expliciete PRIMARY KEY . heeft of een UNIQUE sleutel die kan worden gepromoveerd tot PK, dan is er een ontoegankelijk 6-byte veld (per rij) voor de PK.

• Grote TEXT /BLOB en zelfs VARCHAR worden "off-record" opgeslagen. Dit bemoeilijkt de berekeningen enorm. En het is afhankelijk van welke van de 4 ROW_FORMATs je gebruikt. In sommige gevallen is er een 20-byte "pointer" voor elke dergelijke cel.

• FOREIGN KEY beperkingen voegen niets toe aan de benodigde ruimte, behalve dat ze mogelijk forceer het aanmaken van een index.

• INDEXes , anders dan de PRIMARY KEY zijn niet opgenomen in de avg_row_length.

• De PRIMARY KEY meestal brengt weinig overhead met zich mee in de gegevens Bboom. Een eenvoudige vuistregel is 1% overhead (bovenop de kolom zelf). Deze overhead zijn de niet-bladknooppunten van de Btree.

• Terwijl een InnoDB-transactie bezig is, worden eventuele gewijzigde rijen vastgehouden in de "geschiedenislijst". Dit leidt tot meer overhead.

• (Niet helemaal gerelateerd). InnoDB's COMPRESSED heeft problemen -- het geeft slechts ongeveer 2x compressie, in tegenstelling tot de typische tekstcompressie van 3x. Het kost wat RAM omdat het zowel de gecomprimeerde als de niet-gecomprimeerde gegevens tegelijkertijd in de buffer_pool moet hebben (voor ten minste enkele blokken).

SHOW TABLE STATUS en ophalen van information_schema.TABLES geeft dezelfde gegevens. Er zijn manieren om sommige . te krijgen inzicht in de diepte van de B+Tree voor de data en voor elke tabel.