Le colonne che non sono indici sono ordinate su disco insieme all'indice?

Le colonne che non sono indici, sono ordinate su disco insieme all'indice, in MySQL, in MyISAM e InnoDB?

Un pensiero errato che ho iniziato a scrivere:

Penso che probabilmente no, dal momento che non sono indicizzati; se fossero ordinati ciò significherebbe che sono indici.

Ciò non è corretto perché ogni colonna di indice è ordinata in base all'ordine del proprio contenuto, ma chiedo di essere ordinata per ogni riga (o solo per alcune colonne) con l'indice corrispondente.

Per spiegare, dico: questo sarebbe utile per rendere più veloci la selezione di intervalli di righe, che si trovano fianco a fianco, insieme, per i loro indici. Ad esempio, se voglioselect * where id >1000 and id<2000 (potrebbero esserci errori nella sintassi di MySQL, non lo conosco bene), allora la colonna id stessa può essere letta rapidamente dal disco perché probabilmente le sue celle da 1000 a 2000 stanno insieme sul disco fisico . Tuttavia, altri contenuti di colonne corrispondenti agli ID da 1000 a 2000 possono essere scritti in posizioni diverse sul disco fisico. Se fossero anche ordinati, verrebbero letti più velocemente. Penso che forse MySQL ordina automaticamente quelle colonne sul disco fisico, per eseguire tali operazioni.

Sono ordinati in altri tipi di database (PostgreSQL, ecc.)?

27 dicembre: vedo dalle 2 risposte, che nel caso in cui sia presente l'indice cluster / chiave primaria, le righe semplici stesse non sono ordinate sul disco fisico (come pensavo potesse / potesse essere), e anche l'indice cluster è non ordinato, se è b-tree, ho letto di b-tree e vedo che i suoi nodi, a quanto ho capito, rimangono in punti casuali sul disco.

In alcuni casi possono essere ordinati. L' indice di ordinamento viene in genere chiamato chiave di clustering . In tal caso, l'intera tabella viene archiviata all'interno di tale indice (di solito in una sorta di struttura ad albero B).

Nell'altro caso la struttura della tabella è nota come heap , le righe vengono memorizzate come vengono, eliminando i "buchi" delle foglie nei blocchi di dati e tali buchi vengono successivamente riempiti con nuove righe, quindi nemmeno "l'ordine di inserimento" viene conservato.

MyISAM utilizza la struttura heap , con ogni riga identificata dall'offset (tipo di indice dell'array ) nel file di dati. Ogni indice contiene quindi le colonne indicizzate per ciascuna riga, ordinate nell'ordine corretto e con il numero di offset per individuare la riga reale. Ciò significa che accedere alla riga da qualsiasi indice significa individuare i nodi giusti nell'indice (albero B) e quindi leggere gli offset giusti dal file di dati (può verificarsi una ricerca casuale in una parte diversa del disco ).

InnoDB utilizza il clustering in base alla chiave primaria (o se non ne viene definita nessuna, viene utilizzata la prima chiave univoca non nulla o viene aggiunta una colonna di incremento automatico interna, quindi le righe vengono sempre ordinate in qualche modo). In tal caso, l'accesso dalla chiave primaria è "diretto", quando viene individuato il valore corretto, hai l'intera riga a portata di mano, non è necessario eseguire una seconda lettura. Gli indici secondari d'altra parte non possono memorizzare un offset come in MyISAM (perché l'albero B si sta riequilibrando dinamicamente, quindi l'offset di una riga specifica può cambiare in qualsiasi momento) e memorizzano invece i valori della chiave primaria della riga - quindi un l'accesso da una chiave secondaria significa due ricerche B-tree in InnoDB.

MS SQL Server offre un'opzione per rendere la chiave primaria (o un altro indice) cluster o non cluster, in modo da poter scegliere tra l' heap (nessun indice è cluster) e la struttura ad albero (un indice è cluster). Tutti gli altri indici non cluster memorizzano valori speciali (RowID) nel caso heap o i valori chiave cluster della riga nel caso dell'elemento della configurazione.

PostgreSQL utilizza solo tabelle heap ma ti consente di riordinarle con alcuni indici su richiesta (devi attivarlo, quindi le righe vengono ordinate dopo l'azione ma ulteriori scritture nella tabella possono interrompere di nuovo quell'ordine).

TokuDB (un motore MySQL / MariaDB di terze parti) può utilizzare più chiavi di clustering su una tabella - mantiene efficacemente più copie della tabella, ciascuna ordinata in modo diverso. Viene fornito con una penalità per le scritture, ma TokuDB afferma di usare qualcosa che chiamano indici frattali che dovrebbero rendere tale penalità piuttosto piccola.

Se è necessario utilizzare quella funzionalità per alcune query, è possibile "emularla" creando un indice di copertura - in questo modo le colonne di cui la query necessita sono disponibili nel giusto ordine in qualsiasi momento, ma di nuovo significa mantenere una copia ordinata di (parti di ) la tabella nei tuoi indici.

La risposta breve e semplice per i database in generale è: no, l'ordine fisico delle righe in una tabella non è generalmente lo stesso di un indice su quella tabella.

In generale (dico in generale perché ci sono casi speciali in cui ciò non è vero) la tabella e l'indice sono due diverse strutture fisiche sul disco. I RDBM convenzionali memorizzano i dati in modo che i valori di una riga della tabella (non della colonna ) si trovino uno accanto all'altro sul disco; le righe stesse non sono memorizzate in nessun ordine particolare. Le voci di indice, d'altra parte, sono memorizzate in ordine; un tipico indice b-tree contiene valori ordinati di colonne indicizzate (ma non altre colonne!) e una sorta di puntatore alla posizione dell'intera riga nella tabella che è, come ho detto prima, una struttura fisica separata sul disco.

Detto questo, ci sono casi speciali. Ad esempio, InnoDB di MySQL memorizza le righe di dati effettivi in ​​una struttura simile a un indice. L'indice in base al quale le righe vengono inserite in tale "tabella indice" è in genere la chiave primaria della tabella; e tale indice viene chiamato indice cluster . Ma, naturalmente, una tabella InnoDB può avere altri indici e l'ordinamento di righe (ovvero colonne di riga incluse nel rispettivo indice) in quegli indici non ha nulla a che fare con l'ordinamento di righe nella tabella stessa.