MYSQL Otimizando uma tabela com 137000 linhas

Question

Eu estou tentando otimizar um redmine banco de dados antes que fique muito de uma dor; as alterações (basicamente um registro de todo o SVN Changes) está em 137000 linhas (ish) ea mesa está definido para as configurações padrão ASIC b. Nenhuma chave embalagem etc.

A tabela é a seguinte

ID int[11] Auto Inc (PK)
changeset_id int[11]
action varchar[1]
path varchar[255]
from_path varchar[255]
from_revision varchar[255]
revision varchar[255]
branch  varchar[255]

Índices: primária (ID),
conjunto changeset_id ao Índice BTREE

Tudo sobre charset latin1 baseado em um pouco de informação de http://forge.mysql.com/ wiki / Top10SQLPerformanceTips

O motor de mesa é InnoDB Chaves Pack é definida como padrão (somente pacotes varchar Char)

Todas as outras opções estão desligados.

O que é a melhor maneira de otimizar isso? (Bar truncar; o))

Answer 1

Existem algumas técnicas gerais de otimização para mysql: o primeiro seria se certificar de seus tipos de dados encaixar o ABC (ver aqui ). Indo mais, em seguida, de cima para baixo, ID e changeset_id olhar boa, a ação deve ser provavelmente um char 1 em vez de um varchar (anulável se você pode deixá-lo em branco (e, em geral, verifique se o anulável é definido corretamente em outros campos)). Quanto aos outros 5 campos (que dependendo do tamanho provavelmente dominam a tabela), são strings o tipo de dados correto? (Eu estou supondo que sim com trajeto, from_path, ramo, mas talvez revisão deve ser um número (eu estou supondo que não é assim que suporta git ou algo assim))

Além disso, eles se parecem com as metas de normalização, especialmente desde um "caminhos" e mesa "revisões" iria normalizar quatro deles ( aqui é um básico tutorial , se você precisar dele)

Answer 2

Ele depende inteiramente da sua leitura e gravação características, ou seja, as consultas que você está fazendo, e quantas vezes você está escrevendo para ele.

A maneira de otimizar para a escrita é minimizar o número de índices. Idealmente, você usar o que no servidor MS SQL seria o "índice de cluster" com uma chave monotonamente incrementando, garantindo que você escrever novos registros para o fim da tabela, e você escrever nenhum outro índice separado. Melhor ainda, mesmo, é para ignorar o DBMS e escrever para um arquivo de log antigo planície de algum tipo, se você não precisa de qualquer capacidade transacional.

Para consultas, bem, isso pode ficar tão complexo como você gosta. Tenha em mente, porém, que se você precisar de qualquer quantidade significativa de dados da tabela para uma consulta (ou seja, é mais do que apenas olhar para cima um único registro com base em uma chave), varreduras de tabela pode não ser uma coisa tão ruim. Geralmente, se você está examinando mais de 3-5% do conteúdo de uma mesa, uma varredura da tabela será muito rápido. Mais uma vez, por isso, um arquivo velho liso provavelmente será mais rápido do que um SGBD.

Se você tem que otimizar para ambos, considere otimização para a escrita, e, em seguida, fazer uma cópia em uma base regular que você otimizar para consultas, e fazendo as consultas contra a cópia.