Mais Dicas sobre Otimizações

Dicas não ordenadas para sistemas rápidos:

• Utilize conexões persistentes aos banco de dados para evitar a sobrecarga da conexão. Se você não poder utilizar conexões persistentes e for fazer várias novas conexões para o banco de dados, você pode desejar alterar o valor da variável thread_cache_size. Leia "Parâmetros de Sintonia do Servidor".
• Sempre verifique se todas as suas consultas realmente utilizam os índices que foram criados nas tabelas. No MariaDB você pode fazer isto com o comando EXPLAIN. See Explain: (manual) Explain.
• Tente evitar consultas SELECT complexas em tabelas que são muito atualizadas. Isto evita problemas com travamento de tabelas.
• Com tabelas MyISAM que não tenham linhas deletadas, você pode inserir registros ao mesmo tempo que outra tabela a estiver lendo. Se este recurso é importante para você, deve considerar métodos onde você não tem que apagar registrou ou executar OPTIMIZE TABLE depois de ter apagado vários registros.
• Utilize ALTER TABLE ... ORDER BY expr1,expr2... se você na maioria das vezes recupera registros na ordem expr1,expr2... Utilizando esta opção depois de grandes alterações para a tabela, pode lhe dar um ganho de performance.
• Em alguns casos pode fazer sentido introduzir uma coluna 'hash' baseada nas informações das outras colunas. Se esta coluna for curta e razoavelmente única pode ser muito mais rápido do que ter um grande índice em várias colunas. No MariaDB é muito fácil usar esta coluna extra: SELECT * FROM nome_tabela WHERE hash=MD5(concat(col1,col2)) AND col_1='constante' AND col_2='constante'
• Para tabelas que alteram muito você deve tentar evitar todas colunas VARCHAR ou BLOB. Você terá tamanho de registro dinâmico assim que usar um simples campo VARCHAR ou BLOB. Leia Tipos de Tabela do MariaDB.
• Normalmente não é muito útil cortar uma tabela em diferentes tabelas apenas porque os registros estão 'grandes'. Para acessar um registro, o maior problema para a performance é a busca em disco para encontra o primeiro byte do registro. Depois de encontrar os dados a maioria dos novos discos podem ler o registro inteiro rápido o bastante para a maioria das aplicações. Os únicos caos onde realmente faz sentido dividir uma tabela é se ela é uma tabela de registros com tamanho dinâmico (veja acima) que você pode alterar para um tamanho fixo, ou se você frequentemente precisa examinar a tabela e não precisa da maioria das colunas. Leia Tipos de Tabela do MariaDB.
• Se frequentemente você precisar calcular alguma coisa baseada em informação de vários registros (ex: contagem de registros), provavlmente é melhor introduzir uma nova tabela e atualizar o contador em tempo real. Uma atualização do tipo UPDATE table set count=count+1 where index_column=constante é muito rapida!

  Isto é realmente importante quando você usa bancos de dados como o MariaDB que só tem travamento de tabelas (multiplos leituras/escrita única). Isto também dará melhor performance com a maioria dos banco de dados, já que o gerenciador de bloqueio de registro terá menos a fazer neste caso.

• Se você precisar colerar estatisicas de tabelas maiores, utilize tabelas resumo em vez de buscar em toda a tabela. Manter os resumos deve ser mais rápido que tentar criar estatitíscas instantaneamente. É muito mais rápido criar novas tabelas através dos logs quando as coisas mudam (dependendo das descisões de negócio) que ter que alterar a aplicação em execução.
• Se possível, deve-se classificar relatórios como 'instantâneo' ou 'estatísticos' onde os dados necessários para relatórios estaiísticos são gerados apenas com base nas tabelas resumo que são geradas a partir dos dados atuais.
• Tire vantagem do fato de que a coluna tem valores padrões. Insira valores explicitamente apenas quando os valores a serem inseridos diferem do padrão. Isto reduz a analise que o MariaDB precisa fazer e aumenta a velocidade de inserção.
• Em alguns casos é conveniente empacotar e armazenar os dados em um campo blob. Neste caso você deve adicionar algum código em sua aplicação para empacotar/desempacotar as coisas no campo blob, mas isto pode poupar vários acessos a algum estágio. Isto é prático quando você possui dados que não conformam com uma estrutura estática de tabela.
• Normalmente, você deve tentar manter todos dados não-redundantes (o que é chamado de 3a forma normal na teoria de bancos de dados), mas você não deve ter medo de duplicar alguns itens ou criar tabelas de resumo se você precisar delas para ganhar mais velocidade.
• Stored Procedures ou UDF (funções definidas pelo usuários) pode ser uma boa forma para obter mais performance. Neste caso você deve, entretanto, sempre ter uma maneira de fazer isso de outra maneira (mais lenta) se você utilizar algum banco de dados que não suporta isto.
• Você sempr pode ganhar velocidade fazendo cache de perguntas/respostas na sua aplicação e tentando fazer várias inserções/atualizações ao mesmo tempo. Se seu banco de dados suporta travamento de tabelas (como o MariaDB e Oracle), isto deve ajudar a garantir que o cache de índices é descarregado somente uma vez depois de todas atualizações.
• Use INSERT /*! DELAYED */ quando não precisar saber quando os dados são gravados. Isto melhora a velocidade porque vários registros podem ser gravados com uma simples escrita em disco.
• Use INSERT /*! LOW_PRIORITY */ quando você desejar que suas consultas sejam mais importantes.
• Use SELECT /*! HIGH_PRIORITY */ para obter consultas que ignoram a fila. Isto é, a consulta é feita mesmo se alguem estiver esperando para fazer uma escrita.
• Use a instrução INSERT multi-linhas para armazenar vários registros com um comando SQL (vários servidores SQL suportam isto).
• Use LOAD DATA INFILE para carregar volumes maiores de dados. Isto é mais rápido que as inserções normais e mais rápido até quando o myisamchk for integrado no mysqld.
• Use colunas AUTO_INCREMENT para garantir valores únicos.
• Use OPTIMIZE TABLE de vez em quando para evitar fragmentação quando estiver usando formatos de tabela dinâmica. Leia "Sintaxe de OPTIMIZE TABLE".
• Use tabelas HEAP para obter mais velocidade sempre que possível. Leia Tipos de Tabela do MariaDB.
• Quando estiver usando uma configuração de servidor Web normal, imagens devem ser armazenadas como arquivos. Isto é, armazene apenas uma referência para o arquivo no banco de dados. A principal razão para isto é que um servidor Web normal é muito melhor trabalhando com cache de arquivos do que com conteúdo de banco de dados. Portanto será muito mais fácil obter um sistema rápido se você utilizar arquivos.
• Use tabelas em memória para dados não-críticos que são acessados frequentemente (como informações sobre o último banner visto para usuários que não possuem cookies).
• Colunas com informações identicas em diferentes tabelas devem ser declaradas idênticas e ter nomes idênticos. No entanto, antes da versão 3.23, você pode obter ligações mais lentas.

  Tente manter os nomes mais simples (use nome em vez de nome_cliente na tabela cliente). Para deixar seus nomes portáveis para outros servidores SQL você deve mantê-los menores que 18 caracteres.

• Se você realmente precisa de alta velocidade, você deve verificar as interfaces de baixo nível para armazenagem de dados que os diferentes servidores SQL suportam! Por exemplo, para acessar tabelas MariaDB MyISAM diretamente, você pode obter um aumento de velocidade de 2-5 vezes comparado ao uso da interface SQL. Para conseguir essa façanha, os dados devem estar no mesmo servidor que sua aplicação, e normalmente devem ser acessados por apenas um processo (porque travamento de arquivos externo são muito lentos). Os problemas acima podem ser eliminados introduzindo comandos MyISAM de baixo nível no servidor MariaDB (isto pode ser a maneira mais fácil para aumentar a performance). Tenha cuidado em projetar a interface com o banco de dados, ela deve ser bem facil para suportar estes tipos de otimizações.
• Em vários casos é mais rápido acessar dados de um banco de dados (utilizando uma conexão ativa) do que acessar um arquivo texto, apenas pelo fato do banco de dados ser mais compacto do que o arquivo texto (se você estiver utilizando dados numéricos), e isto irá envolver menos acessos à disco. Você também irá poupar código porque não será necessário analisar seus arquivos texto para encontrar limites de registros e campos.
• Você pode também usar replicação para conseguir ainda mais performance nas suas aplicações. Leia "Replicação no MySQL".
• Declarando uma tabela com DELAY_KEY_WRITE=1 irá tornar a atualização de índices mais rápida, pois as mesmas não serão escritas em disco até o arquivo ser fechado. O lado ruim é que você deve executar myisamchk nestas tabelas antes de iniciar o mysqld para garantir que os dados estão corretos se o mysqld for finalizado no meio da execução. Como a informação de chave pode sempre ser gerada a partir dos dados, você não deve perder nada usando DELAY_KEY_WRITE.

Retornar