Sim : inclusive, clustering factor *** NÂO TEM NADA A VER *** com redução de I/O per se : ele é simplesmente um indicador, uma referência se os dados dentro do índice estão bastante 'espalhados' por múltiplos blocos ou não, e é usado como fator de DESEMPATE para o Otimizador escolher quando houver mais de um índice possível... E Imagino que vc ENTENDEU quando eu disse que o CF é uma medida de organização da tabela, se fisicamente a tabela está organizada mais coerentemente com a coluna X , não tem ao mesmo tempo como ela Também estar organizada fisicamente pela coluna Y ao mesmo tempo....NÃO EXISTE isso de 'melhorar o clustering factor para a query' , o CF é PARA A TABELA COMO UM TODO, okdoc ????
Então SIM, eu Recomendo que vc parte pras opções de Tuning de SQL : via de regra tuning de SQL é muuuuuuito mais simples e muuuuito mais Efetivo, vc consegue resultados melhores de uma maneira mais simples... O passo inicial para tuning de SQL é obter Conhecimento sobre os índices E as tabelas envolvidas na query (o que inclui a razão / regra de negócio que te leva a sub-queries, por exemplo), TEM que saber os volumes estimados para cada acesso via cada índice E tem que conhecer os métodos de JOIn (ie, HASH JOIN, NESTED LOOPs, SORT_mERGE, etc) para poder avaliar o Plano de Execução que o Otimizador vai te dar e validar se ele está o mais otimizado possível ou não... Por exemplo, pegando o exemplo em www.oracle.com/technetwork/database/bi-datawarehousing/twp-explain-the-explain-plan-052011-393674.pdf o Otimizador escolher fazer um HASH JOIN, ie, ler na íntegra as tabelas envolvidas criando uma tabela temporária em memória ordenada e então filtrar os dados por essas tabelas temporárias - isso é RADICALMENTE DIFERENTE de NESTED LOOP, onde ele vai lendo os dados linha a linha e para cada linha lida o RDBMS procura nas outrs tabelas pra ver se tem um valor correspondente.... Qual o melhor/mais correto ? DEPENDE dessas infos que citei.... Na minha experiência pessoal, a fonte que melhor explicou esses diferentes métodos de JOIN foi o livro "Oracle SQL High-Performance Tuning", de Guy Harrison , Recomendo que vc o leia... O passo inicial do método para Tuning de SQL que recomendo portanto é : COM o conhecimento teórico da metodologia do Otimizador de SQL presente E conhecendo também volumes e distribuição de dados nas tabelas e índices envolvidas, obtenha o Plano de Execução extendido (ie, que inclui qtdades estimadas versus qtdades efetivamente obtidas) cfrme https://blogs.oracle.com/optimizer/how-do-i-know-if-the-cardinality-estimates-in-a-plan-are-accurate .... Com isso aí vc vai analisar se o índice e o método de JOIN tão apropriados ou se vc acredita que outro seria mais efetivo, se as Estatísticas que guiam as Estimativas do RDBMS tão apropriadas, é por aí.... []s Chiappa
