vantaggio di BTREE?

Question

Creo gli indici senza la clausola "USING BTREE". C'è qualche vantaggio nell'uso dell'indice BTREE?

CREATE INDEX `SomeName` USING BTREE ON `tbl_Name`(`column_name`); 

Answer 1

BTREE è il metodo di indice predefinito. Puoi tranquillamente ometterlo.

Answer 2

Dipende dal motore di archiviazione che si sta utilizzando. Per la maggior parte, BTREE è il valore predefinito, quindi specificarlo non cambia davvero nulla. Per i motori di memorizzazione come MEMORY/HEAP e NDB, l'impostazione predefinita prevede l'uso degli indici HASH per impostazione predefinita.

Maggiori informazioni possono essere trovate here.

O meno di un B-albero o di un indice di hash è vantaggioso per voi dal punto di vista delle prestazioni dipende dai dati e come si sta accedendo. Se sai che le tue query mirano esattamente a una riga o a righe singole sparse, un indice HASH può essere utile. Qualunque cosa diversa da quella, generalmente preferisco un indice BTREE dato che i dati sono ordinati e quindi rende le query di intervallo e quelle che restituiscono più righe più efficienti.

Answer 3

Prima di tutto, a seconda del motore di archiviazione utilizzato, si può non avere una scelta (InnoDB ad esempio utilizza esclusivamente BTREE per il suo indice).

Inoltre, BTREE è il tipo di indice predefinito per la maggior parte dei motori di archiviazione.

Ora ... In alcuni casi, l'uso di tipi di indice alternativi può migliorare le prestazioni. Ci sono (caso relativamente raro) quando un indice HASH può aiutare. Si noti che quando viene creato un indice HASH, viene prodotto anche un indice BTREE. Questo è in parte dovuto al fatto che gli indici hash possono solo risolvere i predicati di uguaglianza. (una condizione come WHERE Price> 12.0 non può essere gestita da un indice hash).

In breve: continuare a utilizzare BTREE, sia implicitamente (se BTREE è l'impostazione predefinita per la memoria utilizzata), o esplicitamente. Scopri gli altri tipi di indici in modo che tu possa conoscerli in caso di necessità.

Edit: (nella ricerca casi in cui possono essere utilizzati i tipi di indici alternativi)
efficace caso è piuttosto semplice per RTREE indici. Questi sono supportati solo, con MySQL, nel contesto di "SPATIAL" databases, cioè i database che includono il contesto di posizione Geo come Punto e altro oggetto nel modello GIS).

Gli indici HASH sono più generici (non limitati a una particolare applicazione o tipo di dati), e generalmente si può seguire la propria comprensione intuitiva degli hash per ottenere un suggerimento su quando questi potrebbero sovraperformare il vecchio ma fedele BTREE. Come indicato in precedenza, ciò implicherebbe colonne tipicamente cercate con un predicato uguale. Sto indovinando che le tabelle di ricerca relativamente brevi e simili potrebbero trarre vantaggio, a seconda dell'implementazione efficace all'interno di MySQL.

Answer 4

cercare un albero equilibrato significa che tutte le foglie sono alla stessa profondità. Non c'è nessun puntatore sulla pista in testa. In effetti, anche gli alberi B più grandi possono garantire che un piccolo numero di nodi debba essere recuperato per trovare una determinata chiave. Ad esempio, un albero B di 10.000.000 di chiavi con 50 chiavi per nodo non deve mai recuperare più di 4 nodi per trovare una chiave. Un B-tree è un formato di struttura dati speciale per un indice che consente un rapido accesso ai dati nell'indice. Una delle proprietà di questa struttura dati è che l'indice è sempre in equilibrio. Ciò significa che ogni nodo al livello più basso è equidistante dal nodo più in alto, o il nodo radice dell'albero. E ogni lato dell'indice ha lo stesso numero di nodi. I nodi ai livelli più bassi sono noti come nodi foglia. Tutti gli altri nodi sono noti come nodi di ramo. Punti di controllo ad altri rami o nodi foglia.I nodi foglia memorizzano i valori delle colonne indicizzate e il rowid che punta alla riga distinta che contiene quei valori. La distribuzione effettiva dipenderà dal numero di valori dei dati in ciascun intervallo di valori in un albero B con l'obiettivo generale di ridurre il numero di livelli richiesti che devono essere attraversati per ottenere un valore specifico. I vantaggi di una struttura ad albero B sono:

1. Tutti i blocchi foglia hanno la stessa profondità (numero di valori).
2. L'altezza dell'albero B è in genere piuttosto piccola. In alcuni casi, il nodo radice è l'unico nodo foglia e l'altezza è 1.Come le tabelle ottengono più righe inserite in esso, l'indice deve crescere per contenere questo Ma anche nelle tabelle con oltre 1 milione di righe, l'idex B-tree ha in genere un'altezza 3. Nella più grande delle tabelle, l'altezza può essere solo 4. Ciò significa che anche per le tabelle più grandi, ci vogliono solo 4 blocchi per trovare il rowid della riga che stai cercando, questo è estremamente efficiente.
3. Nei casi di dati inseriti casualmente, l'albero B mantiene automaticamente i saldi. Infatti, l'albero B mantiene i saldi indipendentemente dai dati immessi.
4. Tutti i blocchi di un indice B-tree sono pieni di tre quarti (in media), consentendo l'inserimento senza rebulazione. 5.B-tree fornisce prestazioni eccellenti per tutti i tipi di selezioni. 6.Inserire, aggiornare ed eliminare tendono ad essere efficienti in una struttura ad albero B. 7. Le prestazioni dell'albero-albero rimangono ottimali anche quando le tabelle sono piccole o grandi.

Answer 5

La risposta semplificata è che se l'SQL utilizza un'istruzione LIKE su quel campo, l'indice BTREE deve essere superiore a un indice hash. Se stai utilizzando le stesse (=) dichiarazioni contro quel campo, rimani con Hash Index.