Indicizzazione dall'inizio o quando problema di prestazioni si pone?

Question

La mia domanda è per quanto riguarda l'uso di indici.

1. Devo iniziare l'indicizzazione fin dall'inizio o quando problema di prestazioni si pone?

2. Si può anche creare indice temporaneo durante l'esecuzione di una query. Quali sono i pro ei contro di tali tecniche?

Answer 1

Devo iniziare l'indicizzazione fin dall'inizio o quando le prestazioni problema si pone?

strategia di indicizzazione tende ad evolversi come modelli di utilizzo emergono. Detto questo, ci sono anche le strategie e le linee guida di progettazione che possono essere applicati sulla parte anteriore.

• Scegli una chiave di clustering buona . Di solito è possibile determinare l'indice cluster appropriata in fase di progettazione, in base al modello previsto di inserti a una tabella. Se una ragione convincente emerge per un cambiamento nel futuro, così sia.

• Crea il tuo vincoli univoci primarie e altri . Questi saranno applicate da indici univoci.

• Crea le chiavi esterne e gli indici non cluster associati . Le chiavi esterne sono la tua più frequentemente si fa riferimento si uniscono le colonne, in modo da indice sin dall'inizio.

• Crea gli indici per ogni ovviamente altamente selettivo query . Per i modelli di query si conosce già sarà altamente selettivo e propensi a utilizzare le ricerche invece di scansioni.

Oltre quanto sopra, adottare un approccio graduale e olistica di realizzare nuove indici. Con olistico, intendo valutare il potenziale beneficio e l'impatto a tutte le domande e gli indici esistenti nel valutare un'aggiunta.

Un problema non raro in ambienti SQL Server è overindexing, a seguito di una guida dalle DMV indice mancanti e SSMS suggerimenti. Nessuno di questi strumenti di valutare gli indici esistenti e sarà allegramente suggerire la creazione di un nuovo indice 6 colonna piuttosto che aggiungere una singola colonna ad un indice 5 colonna esistente.

-- If you have this
CREATE NONCLUSTERED INDEX [IX_MyTable_MyIndex] ON [dbo].[MyTable] 
(
    [col1] ASC
    , [col2] ASC
    , [col3] ASC
    , [col4] ASC
    , [col5] ASC
)

-- But your query would benefit from the addition of a column
CREATE NONCLUSTERED INDEX [IX_MyTable_MyIndex] ON [dbo].[MyTable] 
(
    [col1] ASC
    , [col2] ASC
    , [col3] ASC
    , [col4] ASC
    , [col5] ASC
    , [col6] ASC
)

-- SSMS will suggest you create this instead
CREATE NONCLUSTERED INDEX [IX_MyTable_AnotherIndexWithTheSameColumnsAsTheExistingIndexPlusCol6] ON [dbo].[MyTable] 
(
    [col1] ASC
    , [col2] ASC
    , [col3] ASC
    , [col4] ASC
    , [col5] ASC
    , [col6] ASC
)

Kimberly Tripp abbia qualche materiale eccellente su indicizzazione strategia che mentre SQL concentrata è applicabile ad altri piattaforme. Per la gente di SQL Server, ci sono alcuni strumenti utili per l'identificazione di duplicati come l'esempio di cui sopra.

Possiamo anche creare indice temporaneo durante l'esecuzione di una query. Cosa sono i pro ei contro di tali tecniche?

Questo di solito si applica solo per le query raramente eseguite, in genere ETL. È necessario valutare:

1. Fa il tempo necessario per creare l'indice di ridurre il tempo di esecuzione della query.
2. fa la testa di lasciare l'indice al posto di manutenzione superano il tempo necessario per creare / cadere quando è necessario.

Answer 2

Non c'è davvero rischi connessi con entrambi gli approcci:

a) Indice fin dall'inizio, ma non si rendono conto di aver creato una serie di indici che non vengono mai utilizzati. Questi aggiungere un po 'in testa (più evidente per le query che i dati Modifica, ma anche con l'ottimizzazione delle istruzioni SELECT cercando di identificare il miglior indice).

Sarà necessario disciplinare te stesso per identificare gli indici non sono più in uso e cercare di rimuoverli (PostgreSQL può fare questo;., Purtroppo MySQL in confronto è molto debole in questa out of the box)

Opzione b) non aggiungere indici fino a quando la gente inizia a lamentarsi, o gli strumenti diagnostici innescare che determinate query sono lenti e potrebbe essere migliorata.

Il rischio che si introduce è che non si dispone di una grande finestra di tempo sufficiente tra quando si nota è necessario l'indice, e quando si deve aggiungere che.

PostgreSQL supporta costruzione indici CONCURRENTLY, che fa ridurre alcuni lo stress da questo requisito aggiuntivo improvviso-index-, ma ci sono alcuni avvertimenti notato nel manuale.

---

Option (b) tende ad essere la mia preferenza, ma penso che un ibrido di entrambe le opzioni è probabilmente la soluzione migliore. Ha a che fare con il livello di fiducia sul fatto che si pensa sarà effettivamente utilizzato un indice.

Ciò che rende questo una discussione particolarmente complessa è che di solito è facile da indici di cambiamento, ma è più difficile da schema di cambiamento. Non voglio per promuovere il reazione ritardata di B come una scusa per essere avventato.

Answer 3

In addition to Mark's answer

You can get a feel by having realistic test data at expected quantities. I've seen many, many (too many) cases where a query runs OK with a 1000 rows but not the million in production.

If you can, work on a copy of production later on,

Of course, I've seen the odd problem only in production because of usage patterns when everything else is identical

Temporary indexes? Outside of ETL load patterns, if you need them once you'll need them again. Don't forget: an index create/drop is a write and is logged = more load

Answer 4

Just to add a few things.

• Temporary indexes are a terrible idea.. unless the index is on a temp table.
• Indexes take up much more dataspace (as well as other overhead) than people realize. Therefore, create them conservatively.

This is my approach.

1. Similar to Mark, make indexes where they make sense, but don't overdue it.
2. You don't have to wait until performance is slow to create new indexes. Whenever you write new SQL, run a query plan (preferably against your prod database). You should be able to see if a new index is required.

3. Don't be afraid to put > 0 or > "" in your where clauses for unused columns.

   1. Ie, lets say you have an index on A,B,C, and D. However, you only have information A,B,D. There is no reason you can't do-

   select * from blah 
   where A="one" 
   and B="two" 
   and C>=""     --to match index
   and D="four"
   
   --This will use your existing index. No need to create a redundant one.

Answer 5

I will try to answer only the first question. If you can estimate even roughly from the beginning how many records you'll have in your tables after a certain amount of time, than I'd say it's better to start from the beginning to design some indexes. Try to use some test tools or test scripts that will automate as many calls as possible for the application calls that you think will be most often used and you'll see what table scans can be avoided from the beginning.

It will be a guess work at the beginning, but in time, as you have proper usage statistics, you'll have a clearer image.