1. Escolha de SqlDataRead e Dataset Vantagens do Sqldataread: A leitura de dados é muito rápida. Caso os dados retornados não necessitem de muito processamento, recomenda-se a utilização de SqlDataReader, cujo desempenho é muito melhor que o datset. Desvantagens: A conexão com o banco de dados não pode ser fechada até que os dados sejam lidos
(o SqlDataReader lê os dados em uma direção de avanço rápido. A classe SqlDataReader fornece uma maneira de ler o fluxo de dados somente de encaminhamento recuperado do banco de dados SQL Server. Ele usa o SQL Server O formato de transmissão de dados de rede nativo lê os dados diretamente da conexão do banco de dados e precisa ser explicitamente fechado a tempo para liberar a conexão de dados a tempo.)
O conjunto de dados lê os dados e os armazena em cache na memória. Desvantagens: Alto uso de memória. Se você precisar processar muito os dados retornados, é melhor usar o Dataset para reduzir as operações de conexão com o banco de dados. Vantagens: Você só precisa se conectar uma vez para fechar a conexão com o banco de dados
. Em geral, se quiser ler uma grande quantidade de dados e não fazer muito processamento nos dados retornados, use SqlDataReader. processamento nos dados retornados, é mais apropriado usar o datset. A escolha de SqlDataReader e Dataset depende para a realização das funções do programa.
2. ExecuteNonQuery e ExecuteScalar
não precisam retornar um conjunto de resultados ao atualizar os dados. É recomendado usar ExecuteNonQuery. Como nenhum conjunto de resultados é retornado, a transmissão de dados da rede pode ser omitida. Ele simplesmente retorna o número de linhas afetadas. Se você precisar apenas atualizar os dados, a sobrecarga de desempenho do ExecuteNonQuery será relativamente pequena.
ExecuteScalar retorna apenas a primeira coluna da primeira linha no conjunto de resultados. Use o método ExecuteScalar para recuperar um único valor (como um número de identificação) do banco de dados. Esta operação requer menos código do que usar o método ExecuteReader para executar as operações necessárias para gerar um único valor nos dados retornados.
*Basta atualizar os dados usando ExecuteNonQuery. A consulta de um único valor usa a opção de vinculação de dados ExecuteScalar
3. Vinculação de dados
Método de ligação geral DataBinder <%# DataBinder.Eval(Container.DataItem, "field name") %> use DataBinder.eval A ligação não se preocupa com a fonte de dados (Dataread ou conjunto de dados). Você não precisa se preocupar com o tipo de dados que eval converterá esse objeto de dados em uma string. Muito trabalho foi feito na ligação subjacente, utilizando capacidades de reflexão. Só porque é conveniente de usar, afeta o desempenho dos dados. Vamos dar uma olhada em <%# DataBinder.Eval(Container.DataItem, "nome do campo") %>. Quando vinculado a um conjunto de dados, DataItem é na verdade um DataRowView (se estiver vinculado a um leitor de dados (dataread), é um IdataRecord). Portanto, convertê-lo diretamente em um DataRowView melhorará muito o desempenho.
<%# ctype(Container.DataItem,DataRowView).Row("field name") %>
*É recomendado usar <%# ctype(Container.DataItem,DataRowView).Row("field name") %> para dados vinculativo. . Quando a quantidade de dados é grande, a velocidade pode ser aumentada centenas de vezes. Preste atenção a dois aspectos ao usá-lo: 1. Você precisa adicionar <%@ Import namespace="System.Data"%> à página. 2. Preste atenção ao caso do nome do campo (preste atenção especial). Se for inconsistente com a consulta, em alguns casos será mais lento que <%# DataBinder.Eval(Container.DataItem, "field name") %>. Se quiser melhorar ainda mais a velocidade, você pode usar o método <%# ctype(Container.DataItem,DataRowView).Row(0) %>. No entanto, sua legibilidade não é alta.
O acima é o método de escrita de vb.net. Em c#: <@% ((DataRowView)Container.DataItem)["field name"] %>
A maneira mais simples de visualizar o status de cada processo de execução na página: você pode visualizar os detalhes se o atributo trace da página for verdadeiro.
1. Use procedimentos armazenados:
1. Desempenho: Os procedimentos armazenados fornecem muitos recursos avançados que não são encontrados na linguagem SQL padrão. Sua capacidade de passar parâmetros e executar expressões lógicas ajuda os designers de aplicativos a lidar com tarefas complexas. Além disso, o procedimento armazenado é armazenado no servidor local, reduzindo a largura de banda de transmissão da rede e o tempo de execução necessário para executar o procedimento. (O procedimento armazenado pré-compilou a instrução sql, portanto sua velocidade de execução é muito mais rápida do que a execução da instrução sql no programa)
2. Estrutura do programa: Do ponto de vista da escalabilidade do programa, o uso de procedimentos armazenados afetará modificações futuras do programa. por conveniência. Por exemplo, se a estrutura do banco de dados for alterada, você só precisará modificar a estrutura de armazenamento correspondente e a parte de chamada do programa. Esta parte não está no escopo deste artigo e pertence ao desenho da estrutura do programa. Portanto, não vou expandir isso aqui.
3. Segurança do programa: ataques de injeção de SQL podem ser evitados usando procedimentos armazenados.
2. Otimização de instruções de consulta (para sql server2000)
Muitas pessoas escrevem instruções sql apenas para esse propósito, sem considerar a eficiência de execução da instrução sql. Aqui forneço apenas um método para otimizar a ordem das tabelas (a otimização e os princípios das instruções SQL serão discutidos em minhas notas de estudo do SQL Server2000).
Para a eficiência de execução das instruções SQL, você pode usar o analisador de consultas do SQL Server2000 para. visualizar o processo de execução das instruções.
Otimizar ordem da tabela: Em circunstâncias normais, o sqlserver otimizará automaticamente as conexões da tabela. Por exemplo: selecione nome, não de A junte B em A. id=B.id junte C em C.id=A.id onde nome='wang'Embora
a tabela A esteja listada primeiro em From, depois em B e, finalmente, É C. Mas o SQL Server pode usar a tabela C primeiro. Seu princípio de seleção é limitar a consulta a uma única linha ou a algumas linhas, para que a quantidade total de dados pesquisados em outras tabelas possa ser reduzida. Na maioria dos casos, o SQL Server fará a escolha ideal, mas se você achar que uma consulta de junção complexa é mais lenta que o esperado, poderá usar a instrução SET FORCEPLAN para forçar o SQL Server a usar as tabelas na ordem em que aparecem. Como no exemplo acima, adicione: SET FORCEPLAN ON.......SET FORCEPLAN OFF A ordem de execução da tabela será executada na ordem que você escreveu. Visualize as duas eficiências de execução no Query Analyzer para escolher a ordem em que as tabelas são unidas.
*Use SET FORCEPLAN para selecionar a sequência de conexão da tabela
3. A otimização da página (.aspx)
concentra-se principalmente em vários atributos da página
1. EnableViewState (o estado de visualização da página). Defina como falso se não houver requisitos especiais. Com ViewState, cada objeto deve primeiro ser serializado em ViewState e depois desserializado via postback, portanto, não há custo para usar ViewState. Use o mínimo de objetos possível e, se possível, reduza o número de objetos colocados no ViewState. O Viewstate pode basicamente ser desabilitado nas seguintes situações:
(1) Controle de página (.ascx)
(2) A página não é devolvida a si mesma.
(3) Nenhum processamento de eventos para controles é necessário.
(4) O controle não possui valores de propriedade dinâmicos ou vinculados a dados (ou é tratado no código para cada postpack).
Desative ViewState para uma única página ou para cada página, como segue: Página única: <%@ Page EnableViewState=" False" %> Cada página: Em web.config <Pages EnableViewState="false" /> EnableSessionState pode manter o valor padrão (só ocupará recursos se a página usar sessionstate). EnableViewStateMac Se não houver requisitos especiais de segurança, mantenha o valor padrão.
2. Layout de página. Recomenda-se usar Flowlayout (elementos são adicionados sem atributos de posicionamento absoluto). Gridlayout (atributos de posicionamento absoluto) produzirá mais código que Flowlayout devido ao uso de posicionamento absoluto, principalmente as informações de posicionamento do controle.
3. Ao liberar o projeto, lembre-se de liberar o status Debug da página.
4. Otimização da linguagem HTML. Minha sugestão é ser proficiente em HTML/JavaScript e usar menos código gerado automaticamente pelo vs.net2003. Ele gerará automaticamente algum código HTML inútil.
5. Definir a navegação inteligente como verdadeira pode melhorar significativamente o desempenho do usuário. Habilitar esta propriedade tem pouco impacto no cliente e no servidor. Ela pode atualizar de forma inteligente as partes que precisam ser atualizadas.
4. Seleção de controles:
Escolha de controles HTML e controles de servidor. A conveniência e a realização funcional trazidas pelos controles de servidor são incomparáveis aos controles HTML. Mas é obtido às custas dos recursos do servidor. Minha sugestão pessoal: se o controle HTML não puder realizar as funções que deseja, e não puder ser alcançado quando combinado com algumas linguagens de script (como javascrpt/vbscript). Só então o controle do servidor será selecionado. Após selecionar o controle do servidor, tente otimizar seu controle, como cancelar alguns estados da página, etc. (veja a otimização do controle especificamente).
Seleção de controles do servidor: Explique principalmente vários controles de dados comuns:
DataGrid: vem com os mais poderosos)
.exibição de dados O controle possui muitas funções práticas integradas, como modificar, excluir, adicionar e paginar dados. Se você precisar apenas exibir dados, tente não escolher o DataGrid (ele armazena todos os dados no viewstate). Embora a Microsoft tenha feito muito trabalho na camada inferior da paginação automática. é conveniente de usar, a sobrecarga de desempenho é enorme.
DataList: possui muito menos funções que o DataGrid. Mas é muito mais personalizável. A exibição exclusiva de dados multilinhas nos traz muita conveniência. Basicamente, ele pode implementar as funções que o DataGrid pode realizar. Portanto, é recomendado usá-lo.
Repetidor: O menos funcional, mas muito personalizável. Recomenda-se usá-lo se você precisar apenas exibir dados. Devido à redução de muitas funções, o consumo de desempenho do servidor é mínimo. Portanto, se for para exibir dados, basicamente escolho Repeater, depois DataList e por fim DataGrid
* tento escolher o controle html. Funções que podem ser implementadas no cliente são implementadas no cliente (com conhecimento em javascript), reduzindo a pressão no servidor. Sequência de seleção do controle de dados: Repeater, DataList, DataGrid
5. Otimização dos controles do servidor:
1.
O viewstate do controle Viewstate é basicamente igual ao viewstate da página. Usado para salvar alguns estados do controle. O princípio de processamento é o mesmo do processamento do estado de visualização da página. Se estiver interessado, você pode usar o Datagrid para vincular dados e testar a quantidade de dados salvos pelo viewstate. Os dados que ele salva são basicamente iguais à quantidade de dados exibidos pelo Datagrid.
2.
O padrão do Ispostpack é falso. Ele precisa ser definido como verdadeiro quando um evento precisa ser gerado.
A otimização do controle depende principalmente de sua familiaridade com este controle. Quanto melhor você compreender o funcionamento interno de um controle, melhor poderá otimizá-lo de forma adequada.
A otimização do desempenho não pode ser explicada em poucas frases. O que escrevi é apenas a ponta do iceberg. A otimização do desempenho depende do acúmulo de experiência diária e da compreensão contínua dos princípios operacionais do programa.
6. Problemas de exceção
Não há necessidade de usar exceções para problemas gerais, como problemas onde o usuário não existe no fórum, a senha do usuário está incorreta, etc., pois instanciar uma exceção requer muitos recursos e requer preenchimento as informações da exceção (tipo de exceção, local da exceção onde a exceção é lançada) etc.), é claro que não é para evitar o uso de exceções, mas para lidar com as exceções necessárias. O princípio para exceções é: não as use se puder, e não gere suas próprias exceções se puder usar as exceções existentes no sistema.