tabelas do banco de dados relacional. Nao vou me ater nos conceitos aprofundados de chaves primarias e indices, deixarei isso para um futuro proximo, vou demonstrar como fazer um teste e verificar a eficacia de se ter tais recursos em suas tabelas.O SGBD utilizado foi o Oracle 11g, entao as queries utilizadas foram criadas em PL\SQL, isso quer dizer que, caso voce teste as mesma em outro banco de dados, no SQL Server por exemplo, aparecerao erros.Lembrando que, o ambiente em que for fazer o teste, pode afetar o desempenho de sua consulta. Processador, memoria e disco rigido, fazem toda a diferenca, resumindo, os resultados que encontrei podem nao ser os mesmos que voce vai encontrar.Primeiramente, vamos criar uma tabela simples, sem nenhuma chave primaria ou indice e faremos a consulta da mesma. Importante: O procedimento abaixo cria uma tabela por meio de uma consulta que gera dados de teste para nosso exemplo, eu criei 10 milhoes de registros, o banco de dados que utilizei fica em um servidor de grande porte, entao aconselho a utilizar menos registros, talvez para um notebook pessoal, um milhao de linhas seja de bom tamanho, fica a dica:CREATE TABLE big_t AS SELECT ROWNUM AS num_uniq , MOD(ROWNUM,10) AS num10 , MOD(ROWNUM,100000) AS num100k , RPAD(rownum,1000,'A') AS texto FROM all_source, all_source WHERE rownum<= 10000000; Este processo demorou exatamente 30,826 segundos para ser executado no meu SGBD.Agora vou testar a tabela fazendo algumas consultas:SELECT COUNT(1) FROM big_t; --101,12 segundosSELECT COUNT(1) FROM big_t; --101,604 segundosSELECT COUNT(1) FROM big_t; --104,24 segundosFiz o teste 3 vezes para ter certeza do tempo de consulta.Agora vou colocar um filtro nessa brincadeira e ver a performance:SELECT COUNT(1) FROM big_t WHERE num10 = 1; --100,605 segundosSELECT COUNT(1) FROM big_t WHERE num10 = 1; --101,760 segundosSELECT COUNT(1) FROM big_t WHERE num10 = 1; --101,791 segundosObserve que nao tenho nenhuma complexidade nessas queries, imagine algo bem maior com joins e agrupamentos, nao vai ficar performatico ne.Agora vamos a "magica" das chaves primarias, segue a criacao da mesma.ALTER TABLE big_t ADD ( CONSTRAINT big_t_pk PRIMARY KEY (num_uniq));Repetirei as consultas realizadas, veja a diferenca que tive no tempo de resposta:SELECT COUNT(1) FROM big_t; --3,229 segundosSELECT COUNT(1) FROM big_t; --1,061 segundosSELECT COUNT(1) FROM big_t; --1,061 segundosDe 100 segundos, cai para 1 segundo, apenas definindo uma chave primaria em minha tabela, imagine a diferenca que isso faz para uma consulta pesada, e muita coisa.Porem, se repetirmos a consulta com o filtro para num10, a performance nao vai mudar, pois a chave primaria ja nao vai ter o mesmo peso que teve na consulta anterior.SELECT COUNT(1) FROM big_t WHERE num10 = 1; --101,51 segundosSELECT COUNT(1) FROM big_t WHERE num10 = 1; --106,033 segundosEntao faco uma nova "magica", adiciono um indice a tabela.CREATE INDEX idx_bigt_num10 ON big_t(num10);Feito isso, vou repetir as consultas com filtro.SELECT COUNT(1) FROM big_t WHERE num10 = 1; --2,075 segundosSELECT COUNT(1) FROM big_t WHERE num10 = 1; --0,686 segundosE impressionante o resultado que obtive, de 106 segundos gastos antes do indice, agora leva-se menos de 1 segundo, gastei decimos de segundo.Vale lembrar que nao basta apenas adicionar indices a torta