Os otimizadores de consulta do banco de dados estão cientes das diferenças de desempenho do armazenamento?

Pelo que entendi, o otimizador de consultas no SQL Server (ou qualquer outro RDBMS, na verdade) não está ciente do desempenho do armazenamento abaixo do banco de dados e tomará decisões como se todo o armazenamento tivesse custo igual. É preciso ou existe algum conhecimento sobre o desempenho do armazenamento que é levado em consideração?

Em um exemplo totalmente artificial, digamos que minhas linhas de tabela sejam armazenadas em uma unidade SSD na minha SAN com tempos de acesso instantâneos, onde meus índices são armazenados em unidades SAS extremamente sobrecarregadas, resultando em saturação e constantes filas de disco. Quando o RDBMS gera o plano de execução, é mais provável favorecer uma varredura de tabela do que uma operação de índice (ou possivelmente um índice fino e pesquisas de tabela associadas, em oposição a um índice de cobertura, porque é menos E / S nos discos SAS)?

Suspeito que a resposta seja sólida "não há chance de o otimizador ser inteligente ou até mesmo ciente do desempenho do disco", mas só queria ver se alguém sabe ao certo. Estou usando o SQL Server, mas estou interessado em qualquer sistema de banco de dados.

O otimizador de consulta do servidor sql não leva em consideração as variações no desempenho do disco ao compilar um plano de consulta. Paul White fornece uma excelente visão geral do otimizador baseado em custo do Sql Server aqui:

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

Alguns pontos-chave são:

• O otimizador não está tentando calcular o custo exato de um plano. Ele está tentando escolher o plano com o menor custo relativo entre várias alternativas.

• É uma visão simplificada da realidade. Ele assume que um servidor pode executar 320 io / s e que o desempenho da CPU não aumentou em mais de uma década.

• Embora os servidores hoje tenham características de desempenho muito diferentes, o otimizador ainda faz um bom trabalho na maioria dos casos.

Então, por que a Microsoft não adiciona alguma inteligência adicional ao otimizador? No futuro, eles podem, no entanto, o que é mais provável são pequenos ajustes nos custos de iteradores individuais. Atualmente, o benefício não existe para justificar o esforço.

Você pode usar chamadas dbcc não documentadas para alterar algumas das suposições dos otimizadores de consulta. NÃO UTILIZE ESTES EM UM SERVIDOR DE PRODUÇÃO

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

Ambos têm valores padrão de 1. Brinque com eles e veja se você consegue criar valores diferentes que produzam consistentemente melhores planos na maioria dos casos. Você descobrirá que pequenas mudanças não mudarão a maioria dos planos e grandes mudanças gerarão planos realmente bizarros.

Um ponto adicional é que, embora o SQL não considere o desempenho io ao compilar um plano, ele responde ao desempenho io durante a execução do plano (limitando as leituras de leitura antecipada se io estiver saturado, etc.)

O otimizador de consulta do Db2 for LUW está ciente das características de desempenho do hardware da máquina em que está sendo executado e as leva em consideração.

Especificamente, cada espaço de tabela possui dois parâmetros numéricos que refletem o desempenho do armazenamento subjacente:, overheadque reflete a sobrecarga do controlador de E / S, o tempo de busca e latência do disco em milissegundos e transferrateindica o tempo necessário para transferir uma página do espaço de tabela do disco para a memória.

Esses parâmetros podem ser especificados no momento da criação do espaço de tabela para substituir os valores padrão derivados heuristicamente.

Os parâmetros de desempenho de E / S, juntamente com o cpu_speedparâmetro no nível do gerenciador do banco de dados, são usados ​​pelo otimizador para calcular o custo de E / S e CPU de cada operador do plano de consulta e, portanto, afetam qual plano é finalmente escolhido. Posteriormente, seu cenário seria completamente plausível no DB2. Da mesma forma, em um sistema com velocidade de CPU muito alta e desempenho mais ou menos em disco, o otimizador pode preferir operadores intensivos em CPU (por exemplo, varredura de tabela e classificação) a mais intensivos em E / S (por exemplo, acesso a tabela com base em índice).

Acredito que o Db2 for z / OS também represente as características de desempenho de hardware subjacentes, obtendo-as da camada de gerenciamento de armazenamento, não como parte da configuração do banco de dados.