Querysnelheid gebaseerd op volgorde van kolommen

Het antwoord is ja, het maakt wel degelijk uit, en het kan er veel toe doen, maar meestal niet veel.

Alle I/O wordt gedaan op paginaniveau (meestal 2K of 4K, afhankelijk van uw besturingssysteem). Kolomgegevens voor rijen worden naast elkaar opgeslagen, behalve wanneer de pagina vol raakt, in welk geval de gegevens op de andere (meestal de volgende) pagina worden geschreven.

Hoe groter de gegevensruimte op de schijf die nodig is voor kolommen tussen (op basis van de tabeldefinitie) de kolommen die u selecteert, hoe groter de kans dat de gegevens voor de geselecteerde kolommen (soms) op verschillende pagina's staan. Als u zich op een andere pagina bevindt, kan dit leiden tot een extra I/O-bewerking (als er geen andere rijen zijn geselecteerd op de andere pagina). In het ergste geval kan elke geselecteerde kolom op een andere pagina staan.

Hier is een voorbeeld:

create table bad_layout (
num1 int,
large1 varchar(4000),
num2 int,
large2 varchar(4000),
num3 int,
large3 varchar(4000)
);

create table better_layout (
num1 int,
num2 int,
num3 int,
large1 varchar(4000),
large2 varchar(4000),
large3 varchar(4000)
);

Vergelijken:selecteer num1, num2, num3 uit bad_layout;selecteer num1, num2, num3 uit better_layout;

Omdat voor bad_layout elke num-kolom in principe op een andere pagina staat, vereist elke rij 3 i/O-bewerkingen. Omgekeerd, voor better_layout zullen num kolommen meestal op dezelfde pagina staan.

De uitvoering van de bad_layout-query duurt waarschijnlijk ongeveer 3 keer langer.

Een goede tabellay-out kan een groot verschil maken voor de prestaties van query's. U moet proberen kolommen die gewoonlijk bij elkaar worden geselecteerd zo dicht mogelijk bij elkaar te houden in de tabellay-out.