A otimização do desempenho SQL é um grande desafio para os programadores, porque muitas vezes encontramos este problema: quando desenvolvemos um projeto, sentimos que a experiência funcional de testá-lo por nós mesmos é muito boa, mas depois que o projeto real é lançado, Com o aumento maciço em dados, a experiência do cliente no sistema está cada vez pior. Claro, além da estrutura e do código irracional, o principal motivo é que o SQL não foi otimizado, o que fez com que o sistema ficasse cada vez mais lento.
Como trabalho em uma empresa pequena, faço de tudo, acho que às vezes é melhor tratar os sintomas do que tratar a causa raiz! Existem vários problemas aos quais prestar atenção:
1. O design da tabela do banco de dados deve ser razoável, especialmente o design da chave primária. Se a quantidade de dados na tabela for muito grande, o design da chave primária não deve ser significativo, assim como o ROWID, como o. GUID do SQL Server, o UUID do Hibernate, etc. É claro que algumas tabelas de dicionário de dados podem ser processadas de maneira flexível e não há necessidade de considerar que devem ser chaves primárias físicas. No design de chave primária, geralmente não são usadas chaves primárias compostas.
2. Indexação razoável. O índice é uma ferramenta poderosa e um bom meio para acelerar nossa consulta de dados. Mas não adicione todos os campos. O princípio da indexação é como o índice de um livro. Se o índice do seu livro tiver quase todo o mesmo nome, você pode imaginar o seguinte com que rapidez você pode encontrar o conteúdo específico de acordo com o índice. ? O índice não precisa necessariamente ser único, mas não deve conter muitos registros idênticos. Além disso, se mais índices forem adicionados, o espaço de tabela TEMP aumentará. Ao exportar a tabela e importá-la para outro banco de dados, os índices também reduzirão a eficiência da importação. Neste momento, você também descobrirá que o espaço de tabela UNDOTBS01. é anormalmente grande. Portanto, o índice é uma faca de dois gumes e deve ser aplicado de forma razoável.
3. Tenho visto alguns artigos muito profissionais sobre otimização de SQL na Internet, mas sinto que não consegui usá-los em meu projeto. Em vez disso, continuei a experimentar e a descobrir alguns princípios básicos durante o projeto. Pessoalmente, acho que existe apenas um princípio de otimização de SQL, que é restringir ao máximo o escopo da consulta. Isso certamente melhorará a eficiência, e o próprio Oracle pode otimizar o SQL que escrevemos, então o que precisamos fazer é. estreitar o escopo da consulta tanto quanto possível. Falando nisso, acho que todos certamente pensarão que a indexação é uma ferramenta poderosa para melhorar a velocidade da consulta. .
A maior parte do SQL que precisa ser otimizado são consultas de junção de múltiplas tabelas, e as junções de múltiplas tabelas também incluem junções horizontais e verticais. A conexão horizontal geralmente significa que as estruturas de campo de duas tabelas são basicamente as mesmas, e alguns registros de dados de uma tabela devem ser alterados para alguns registros de outra tabela, ou seja, Linhas + Linhas. Conexão vertical significa que pegamos alguns campos a serem consultados da tabela A e alguns campos a serem consultados da tabela B e, em seguida, conectamos as tabelas retiradas das tabelas A e B verticalmente usando a parte comum, ou seja, Colunas + Colunas.
Instrução de junção horizontal: selecione a.coluna1,a.coluna2 da tabelaA a união todos selecione b.coluna1,b.coluna2 da tabelaB b
Observe que ao conectar horizontalmente, o número de colunas deve ser o mesmo e os tipos de dados das colunas de campo correspondentes devem ser os mesmos. Na verdade, você pode pensar nas tabelas a serem unidas como uma cópia da outra, exatamente iguais. Alguém pode perguntar: se as colunas que desejo mesclar têm colunas diferentes ou se não há nenhuma coluna, você pode usar o seguinte método
selecione d.dname,d.loc de dept1 d union all select '' dname, e.loc de dept e, veja "'' dname", podemos facilmente descobrir que você pode encontrar um substituto, use uma string vazia. não há campos, então eles podem ser mesclados.
Instrução de junção vertical: selecione a.column1,a.column2 da tabelaA uma junção externa completa selecione b.column3,b.column4 da tabelaB b em a.aid=b.bid onde..., este é um formato de junção externa completa. Essa velocidade é realmente muito rápida, mas você pode não gostar da consulta, porque há algumas linhas de resultados que você talvez não queira ver. Em circunstâncias normais, usamos mais a junção externa esquerda e a junção externa direita. A diferença entre os dois é que a junção externa esquerda é baseada principalmente na tabela correspondente ao campo de junção à esquerda, e a junção externa direita é exatamente o oposto. Claro que você também pode usar junção à esquerda, junção à direita. Durante o uso, ainda descobri que as conexões externas são relativamente mais rápidas.
Para acelerar a eficiência das consultas de conexão vertical, o jeito é aninhar as consultas. A seguir está um exemplo real do projeto:
selecione c.customerid,c.receivedmoney,c.tollcollector,c.receiveddate,c.yearmonth,c.receivedlatefee,
c.receivedfee,c.receivedappend,c.jmman,c.jmmoney,c.name,d.chargeint de
(selecione a.customerid,a.receivedmoney,a.tollcollector,a.receiveddate,a.yearmonth,a.receivedlatefee,
a.taxa recebida,a.receivedappend,a.jmman,a.jmmoney,b.nome de
(selecione rf.customerid,rf.receivedmoney,rf.tollcollector,rf.receiveddate,rf.yearmonth,rf.receivedlatefee,
rf.receivedfee,rf.receivedappend,rf.jmman,rf.jmmoney de sf_receivedfee rf onde
rf.electriccompanyid='1000000001' e rf.dealsign=0 e rf.yearmonth em (200811,200901,200903,200804,200805,200806,200807)
e rf.customerid=1000052545) uma junção externa esquerda (selecione xe.employeeid,xe.name de xt_employee xe) b em a.tollcollector=b.employeeid)
c junção externa esquerda (selecione cp.chargeint,cp.customerid de sf_chargeprotocol cp onde cp.customerid=1000052545) d
em c.customerid=d.customerid
Você pode ver que neste exemplo, primeiro filtramos os registros necessários de cada tabela usando quase as mesmas condições e, em seguida, mesclamos os registros. No uso real, descobri que isso é quase 60 vezes mais rápido do que a consulta de link direto. Embora seja feio e difícil de ler, resolve o problema de desempenho do SQL. O princípio que ele usa ainda é restringir primeiro o escopo e depois realizar uma consulta de conexão. Se conectarmos e depois filtrarmos, é equivalente a mesclar duas tabelas e, em seguida, buscar os dados com base nas condições.