Navegação · Definir como página inicial · Adicionar aos favoritos · Móvel Tencent · Página inicial da Tencent Notícias Blog Fórum Comentários Finanças Valores Mobiliários Fundos de Ações de Hong Kong Entretenimento Estrelas Filmes Música Esportes NBA Futebol Abrangente Carros Imóveis Eletrodomésticos Tecnologia Digital Mobile Downloads Emoções femininas Paternidade Moda Compras Viagem Leitura Original Educação Indo para o exterior Jogos Anime Animação Constelações Vídeo Imagens ao vivo Expo Caridade Crianças Novo popular disco de ouro chinês quente Visite o mundo colorido da moda e dos produtos de luxo Celulares nacionais mais vendidos Siga a lista de classificação para ver quais celebridades fazem aniversário hoje Sua localização: Tencent. Página inicial > Tecnologia e Digital > Digital Scroll News > Texto
Catch-21 para desenvolvimento de banco de dados SQL Server http://digi.QQ.com 21 de dezembro de 2009 09:43 Zhongguancun Online Se você é responsável por um projeto baseado em SQL Server ou é novo no SQL Server, você tem Você pode estar enfrentando alguns problemas de desempenho do banco de dados, e este artigo fornecerá algumas orientações úteis (a maioria das quais também pode ser usada com outros SGBDs).
Aqui, não vou apresentar dicas para usar o SQL Server, nem posso fornecer uma solução que resolva tudo. O que faço é resumir algumas experiências sobre como formar um bom design. Essa experiência vem do que aprendi nos últimos anos, onde vi muitos dos mesmos erros de design repetidos continuamente.
1. Conheça as ferramentas que você usa
Não subestime isso, é o ponto mais crítico que abordarei neste artigo. Talvez você também tenha visto que muitos programadores SQLServer não dominam todos os comandos T-SQL e as ferramentas úteis fornecidas pelo SQLServer.
"O quê? Vou perder um mês aprendendo comandos SQL que nunca usarei???", você pode dizer. Certo, você não precisa fazer isso. Mas você deveria passar um fim de semana analisando todos os comandos T-SQL. Sua tarefa aqui é entender que no futuro, ao criar uma consulta, você se lembrará: "A propósito, aqui está um comando que pode realizar totalmente a função que preciso", então vá ao MSDN para verificar a sintaxe exata de este comando.
Deixe-me repetir novamente: não use cursores. Se você deseja destruir o desempenho de todo o sistema, eles são sua primeira escolha mais eficaz. A maioria dos iniciantes usa cursores sem perceber o impacto que eles têm no desempenho. Eles ocupam memória, trancam mesas de todas as maneiras estranhas e funcionam como um caracol. E o pior é que eles podem fazer com que toda otimização de performance que seu DBA possa fazer seja equivalente a não fazê-la. Você sabia que toda vez que executa FETCH, você executa um comando SELECT? Isso significa que se o seu cursor tiver 10.000 registros, ele executará 10.000 SELECTs! Será muito mais eficiente se você usar um conjunto de SELECT, UPDATE ou DELETE para concluir o trabalho correspondente.
Os iniciantes geralmente pensam que usar cursores é uma forma de programação mais familiar e confortável, mas, infelizmente, isso pode levar a um desempenho ruim. Obviamente, o objetivo geral do SQL é o que você deseja alcançar, e não como.
Certa vez, reescrevi um procedimento armazenado baseado em cursor usando T-SQL. A tabela tinha apenas 100.000 registros. O procedimento armazenado original levou 40 minutos para ser concluído, mas o novo procedimento armazenado levou apenas 10 segundos. Aqui, acho que você deveria conseguir ver o que um programador incompetente está fazendo! ! !
Às vezes podemos escrever um pequeno programa para recuperar e processar dados e atualizar o banco de dados, o que às vezes é mais eficiente. Lembre-se: o T-SQL não pode fazer nada em relação aos loops.
Deixe-me lembrá-lo novamente: não há benefícios em usar cursores. Nunca vi nada feito de forma eficaz usando cursores, exceto para trabalho de DBA.
3. Padronize suas tabelas de dados
Por que não normalizar o banco de dados? Provavelmente existem duas desculpas: motivos de desempenho e pura preguiça. Quanto ao segundo ponto, mais cedo ou mais tarde você terá que pagar por isso. E em relação ao desempenho, você não precisa otimizar algo que não seja nada lento. Muitas vezes vejo programadores "desnormalizando" um banco de dados porque o motivo é "o design original era muito lento", mas muitas vezes o resultado é que eles tornam o sistema mais lento. O SGBD foi projetado para lidar com bancos de dados canônicos, então lembre-se: projete o banco de dados de acordo com os requisitos de canonicalização.
4. Não use SELECT *
Isto não é fácil de fazer, como eu sei muito bem, porque eu mesmo faço isso o tempo todo. Porém, se você especificar as colunas necessárias em SELECT, isso trará os seguintes benefícios:
1 Reduza o consumo de memória e a largura de banda da rede
2 Você pode obter um design mais seguro
3 Dê ao otimizador de consulta a chance de ler todas as colunas obrigatórias do índice
Página 2: Entenda o que você fará com seus dados
Criar um índice robusto para seu banco de dados é uma coisa boa. Mas fazer isso é simplesmente uma arte. Sempre que você adicionar um índice a uma tabela, SELECT será mais rápido, mas INSERT e DELETE serão significativamente mais lentos porque criar e manter o índice requer muito trabalho extra. Obviamente, a chave para a questão aqui é: que tipo de operação você deseja realizar nesta tabela. Este problema não é fácil de entender, especialmente quando se trata de DELETE e UPDATE, porque essas instruções geralmente contêm comandos SELECT na parte WHERE.
6. Não crie um índice na coluna “Gênero”
Primeiro, devemos entender como os índices aceleram o acesso a uma tabela. Você pode pensar nos índices como uma forma de dividir uma tabela com base em determinados critérios. Se você criar um índice em uma coluna como “gênero”, estará simplesmente dividindo a tabela em duas partes: masculino e feminino. Você está lidando com uma tabela com 1.000.000 de registros. Qual é o significado desta divisão? Lembre-se: manter índices é demorado. Ao projetar o índice, siga esta regra: organize as colunas da maior para a menor de acordo com o número de conteúdos diferentes que a coluna pode conter, como: nome + província + gênero.
7. Use transações
Use transações, especialmente quando as consultas forem demoradas. Se algo der errado com seu sistema, isso salvará sua vida. Geralmente, os programadores com alguma experiência entenderão que muitas vezes você encontra algumas situações imprevisíveis que farão com que o procedimento armazenado trave.
8. Cuidado com impasses
Acesse suas tabelas em uma determinada ordem. Se você bloquear a tabela A primeiro e depois bloquear a tabela B, elas deverão ser bloqueadas nesta ordem em todos os procedimentos armazenados. Se você (acidentalmente) bloquear a tabela B primeiro e depois bloquear a tabela A em um procedimento armazenado, isso poderá causar um conflito. Se a sequência de bloqueio não for projetada detalhadamente com antecedência, o impasse não será fácil de detectar.
Uma pergunta frequente é: Como posso adicionar rapidamente 100.000 registros a um ComboBox? Isso não está certo e você não pode e não precisa fazer isso. É muito simples. Se o seu usuário tiver que navegar em 100.000 registros para encontrar o registro que precisa, ele definitivamente irá te amaldiçoar. Aqui, o que você precisa é de uma UI melhor e exibir no máximo 100 ou 200 registros para seus usuários.
Comparados aos cursores do lado do servidor, os cursores do lado do cliente podem reduzir a sobrecarga do servidor e da rede e também reduzir o tempo de bloqueio.
11. Use consulta de parâmetro
Às vezes, vejo perguntas como esta no fórum técnico da CSDN: "SELECT * FROM aWHEREa.id='A'B, ocorre uma exceção devido à consulta de aspas simples, o que devo fazer?", e a resposta comum é: use dois Aspas simples em vez de aspas simples. Isso está errado. Isso trata os sintomas e não a causa raiz, porque você também encontrará esses problemas com outros personagens, sem mencionar que causará bugs graves. Além disso, também impedirá que o sistema de buffer do SQL Server funcione como deveria. Ao usar a consulta parametrizada, todos esses problemas desaparecem.
12. Use grandes bancos de dados de dados ao codificar programas
O banco de dados de teste usado pelos programadores no desenvolvimento geralmente não possui uma grande quantidade de dados, mas muitas vezes o usuário final possui uma grande quantidade de dados. Nossa abordagem usual está errada, e a razão é muito simples: os discos rígidos não são muito caros agora, mas por que os problemas de desempenho não são percebidos até que sejam irreversíveis?
13. Não use INSERT para importar grandes quantidades de dados
Por favor, não faça isso a menos que seja absolutamente necessário. Use UTS ou BCP para obter flexibilidade e velocidade de uma só vez.
14. Preste atenção aos problemas de tempo limite
Ao consultar o banco de dados, o valor padrão do banco de dados geral é relativamente pequeno, como 15 segundos ou 30 segundos. Algumas consultas demoram mais para serem executadas, especialmente quando a quantidade de dados no banco de dados continua a aumentar.
Página 3: Não ignore o problema de modificar o mesmo registro ao mesmo tempo
15. Não ignore o problema de modificar o mesmo registro ao mesmo tempo
Às vezes, dois usuários modificarão o mesmo registro ao mesmo tempo. Desta forma, se o último modificador modificar as operações do modificador anterior, algumas atualizações serão perdidas. Lidar com esta situação não é difícil: crie um campo de carimbo de data/hora, verifique-o antes de escrever, mescle as modificações se permitido e avise o usuário se houver conflito.
16. Ao inserir registros na tabela de detalhes, não execute SELECT MAX(ID) na tabela principal
Este é um erro comum que causa erros quando dois usuários inserem dados ao mesmo tempo. Você pode usar SCOPE_IDENTITY, IDENT_CURRENT e IDENTITY. Se possível, não use IDENTITY, pois pode causar problemas na presença de gatilhos (veja a discussão aqui).
17. Evite definir colunas como NULLable
Se possível, você deve evitar tornar as colunas NULLable. O sistema alocará um byte extra para cada linha da coluna NULLable, o que causará mais sobrecarga do sistema durante a consulta. Além disso, tornar as colunas NULLable complica a codificação porque essas colunas devem ser verificadas sempre que são acessadas.
Não estou dizendo que NULLS sejam uma fonte de problemas, embora algumas pessoas pensem assim. Acho que criar uma coluna NULLable às vezes pode funcionar bem se você tiver "dados nulos" permitidos em suas regras de negócios, mas usar NULLable em uma situação como a abaixo está causando problemas.
NomeDoCliente1
EndereçoDoCliente1
E-mail do Cliente1
NomeDoCliente2
EndereçoDoCliente2
E-mail do Cliente3
NomeDoCliente1
EndereçoDoCliente2
E-mail do Cliente3
Se isso acontecer, você precisará normalizar sua tabela.
18. Tente não usar o tipo de dados TEXT
Não use TEXT a menos que esteja lidando com um conjunto de dados muito grande. Porque não é fácil de consultar, é lento e desperdiçará muito espaço se não for usado corretamente. Em geral, VARCHAR pode lidar melhor com seus dados.
19. Tente não usar tabelas temporárias
Tente não usar tabelas temporárias, a menos que seja absolutamente necessário. Geralmente, subconsultas podem ser usadas em vez de tabelas temporárias. Usar tabelas temporárias trará sobrecarga ao sistema, e se você estiver programando com COM+, também trará muitos problemas, porque o COM+ usa um pool de conexões de banco de dados e a tabela temporária existe do começo ao fim. O SQL Server fornece algumas alternativas, como o tipo de dados Tabela.
20. Aprenda a analisar e consultar
O SQL Server Query Analyzer é seu melhor amigo, por meio do qual você pode entender como as consultas e os índices afetam o desempenho.
21. Use integridade referencial
Definir chaves primárias, restrições exclusivas e chaves estrangeiras pode economizar muito tempo.