Gli ottimizzatori di query del database sono consapevoli delle differenze nelle prestazioni di archiviazione?

A quanto mi risulta, Query Optimizer in SQL Server (o qualsiasi altro RDBMS, in realtà) non è a conoscenza delle prestazioni dell'archiviazione sotto il database e prenderà decisioni come se tutto l'archiviazione abbia lo stesso costo. È accurato o è stata presa in considerazione una conoscenza delle prestazioni di archiviazione?

In un esempio totalmente inventato, supponiamo che le mie righe di tabella siano archiviate su un'unità SSD nella mia SAN con tempi di accesso istantanei, in cui i miei indici sono memorizzati su unità SAS estremamente sovraccariche, con conseguente saturazione del disco e code del disco costanti. Quando RDBMS genera il piano di esecuzione, è più probabile che favorisca una scansione della tabella rispetto a un'operazione sull'indice (o forse un indice scarno e ricerche di tabella associate, al contrario di un indice di copertura, perché è meno I / O sui dischi SAS)?

Ho il sospetto che la risposta sia un solido "non è una possibilità l'ottimizzatore che intelligente o addirittura consapevole delle prestazioni del disco", ma volevo solo vedere se qualcuno là fuori lo sa per certo. Sto usando SQL Server, ma sono interessato a qualsiasi sistema di database.

Query Optimizer del server SQL non prende in considerazione le variazioni delle prestazioni del disco durante la compilazione di un piano di query. Paul White offre un'ottima panoramica dell'ottimizzatore basato sui costi di Sql Server qui:

https://sqlkiwi.blogspot.com/2010/09/inside-the-optimizer-plan-costing.html

Alcuni punti chiave sono:

• L'ottimizzatore non sta cercando di calcolare il costo esatto di un piano. Sta cercando di scegliere il piano con il costo relativamente basso tra diverse alternative.

• È una visione semplificata della realtà. Presuppone che un server sia in grado di eseguire 320 io / sec e che le prestazioni della CPU non siano aumentate da oltre un decennio.

• Anche se i server oggi hanno caratteristiche prestazionali molto diverse, l'ottimizzatore fa ancora un ottimo lavoro nella maggior parte dei casi.

Quindi, perché Microsoft non aggiunge ulteriore intelligenza all'ottimizzatore? In futuro potrebbero, tuttavia, ciò che è più probabile sono piccole modifiche ai costi dei singoli iteratori. Attualmente il vantaggio non è lì per giustificare lo sforzo.

È possibile utilizzare le chiamate dbcc non documentate per modificare alcuni dei presupposti di Query Optimizer. NON UTILIZZARE QUESTI SU UN SERVER DI PRODUZIONE

DBCC SETIOWEIGHT(<multiplier>)
DBCC SETCPUWEIGHT(<multiplier>)

Entrambi hanno valori predefiniti di 1. Gioca con loro e vedi se riesci a trovare valori diversi che producono costantemente piani migliori nella maggior parte dei casi. Scoprirai che piccoli cambiamenti non cambieranno la maggior parte dei piani e grandi cambiamenti genereranno piani davvero bizzarri.

Un altro punto è che mentre SQL non considera le prestazioni di io durante la compilazione di un piano, risponde alle prestazioni di io durante l'esecuzione del piano (limitando le letture in lettura se io è saturo, ecc.)

L'ottimizzatore di query Db2 per LUW è a conoscenza delle caratteristiche prestazionali dell'hardware della macchina su cui è in esecuzione e le prende in considerazione.

In particolare, ogni tablespace ha due parametri numerici che riflettono le prestazioni di archiviazione sottostanti:, overheadche riflette l'overhead del controller I / O e il tempo di ricerca e latenza del disco in millisecondi e transferrateche indica il tempo necessario per trasferire una pagina del tablespace dal disco alla memoria.

Questi parametri possono essere specificati al momento della creazione del tablespace per sovrascrivere i valori predefiniti derivati ​​euristicamente.

I parametri delle prestazioni I / O, insieme al cpu_speedparametro a livello di gestore database, vengono utilizzati dall'ottimizzatore per calcolare I / O e il costo della CPU di ciascun operatore del piano di query e influiranno quindi sul piano scelto. Successivamente, il tuo scenario sarebbe completamente plausibile in Db2. Allo stesso modo, su un sistema con una velocità della CPU molto elevata e quindi prestazioni del disco così ottimizzatore potrebbe preferire gli operatori a uso intensivo della CPU (ad es. Scansione della tabella più ordinamento) a quelli a maggiore intensità di I / O (ad es. Accesso alla tabella basato su indice).

Credo che Db2 per z / OS conti allo stesso modo delle caratteristiche di prestazione hardware sottostanti, ottenendole dal livello di gestione della memoria, non come parte della configurazione del database.