De vez em quando, os consumidores dos meus processos de banco de dados pedem uma estimativa de quando uma determinada tarefa será realizada. Embora eu sinta que sei como ler um EXPLAIN na maioria dos mecanismos de banco de dados, tenho problemas para tentar traduzir isso para "me pergunte novamente em 15 minutos". Alguém conhece uma boa "regra de ouro" para usar em qualquer banco de dados específico?
Sei que essa não será uma regra rígida e rápida, mas até mesmo ser capaz de fornecer uma estimativa aproximada pode ser útil em alguns casos.
Eu suspeito que isso não seja possível do jeito que você imagina. Uma razão importante é que o tempo de execução real é muito dependente do hardware, e muitas das decisões de otimização que o mecanismo de banco de dados toma são efetivamente sobre equilibrar o uso dos diferentes componentes de hardware (por exemplo, disco, memória, CPU).
Sugiro que você execute várias consultas relevantes para seu aplicativo, registre as estimativas de custo e os tempos de execução e tente entender esses dados. Você pode obter uma boa relação linear ou pode aprender que os números de custo são inúteis para essa finalidade.
Todos os otimizadores baseados em custo funcionam por meio de uma variedade de algoritmos proprietários (ou você pode lê-los para bancos de dados de código aberto), mas normalmente funcionam atribuindo a uma operação de referência um valor de 1. Por exemplo, no SQL Server, uma operação com uma estimativa de custo de 1 leva 1/320 de segundo em um computador de referência sob a mesa de algum desenvolvedor em Redmond. O custo é apenas uma suposição relativa de quão cara será uma consulta. Muitos RDBMSes usam esse custo para estabelecer prioridade ou, no caso de impasses, para eliminar consultas mais baratas (elas levam menos tempo para serem executadas novamente). Mas tudo isso é apenas um palpite baseado nas informações que o otimizador de consulta tem à sua disposição no momento em que a consulta está sendo executada.
Peter está correto, o melhor que você pode esperar é executar algumas consultas de benchmark em cenários ideais e usá-los para basear as melhores suposições. Você tem que lidar com vários pontos diferentes de contenção em um RDBMS, então é difícil determinar especificamente como qualquer consulta será executada no mundo real.