Pelo que entendi, o otimizador de consulta no SQL Server (ou qualquer outro RDBMS, na verdade) não está ciente do desempenho do armazenamento sob o banco de dados e tomará decisões como se todo o armazenamento tivesse custo igual. Isso é preciso ou há algum conhecimento de desempenho de armazenamento que é levado em consideração?
Em um exemplo totalmente artificial, digamos que minhas linhas de tabela sejam armazenadas em uma unidade SSD em minha SAN com tempos de acesso instantâneos, onde meus índices são armazenados em unidades SAS extremamente sobrecarregadas, resultando em saturação de disco e filas de disco constantes. 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 IO nos discos SAS)?
Suspeito que a resposta seja sólida "sem chance de o otimizador ser inteligente ou mesmo ciente do desempenho do disco", mas eu 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 variações no desempenho do disco ao compilar um plano de consulta. Paul White fornece uma ótima 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. É tentar 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.
Mesmo que os servidores hoje tenham características de desempenho muito diferentes, o otimizador ainda faz um trabalho muito bom 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 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 OS USE EM UM SERVIDOR DE PRODUÇÃO
Ambos têm valores padrão de 1. Brinque com eles e veja se consegue chegar a valores diferentes que consistentemente produzem planos melhores 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 de io ao compilar um plano, ele responde ao desempenho de io durante a execução do plano (limitando leituras de leitura antecipada se io estiver saturado, etc.)
O otimizador de consulta Db2 for LUW está ciente das características de desempenho de hardware da máquina em que está sendo executado e as leva em consideração.
Especificamente, cada tablespace tem dois parâmetros numéricos que refletem o desempenho de armazenamento subjacente:
overhead, que reflete a sobrecarga do controlador de E/S e o tempo de latência e busca de disco em milissegundos, etransferrate, que indica o tempo necessário para transferir uma página de tablespace do disco para a memória.Esses parâmetros podem ser especificados no momento da criação do tablespace para substituir os valores padrão derivados heuristicamente.
Os parâmetros de desempenho de E/S, juntamente com o
cpu_speedparâmetro de nível de gerenciador de banco de dados, são usados pelo otimizador para calcular o custo de E/S e CPU de cada operador de plano de consulta e, portanto, afetarão qual plano será 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 de disco mais ou menos, o otimizador pode preferir operadores intensivos de CPU (por exemplo, varredura de tabela e classificação) a outros mais intensivos de E/S (por exemplo, acesso à tabela baseado em índice).Acredito que o Db2 para z/OS também considera 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.