mysql - table - MyISAM versus InnoDB




innodb vs myisam table lock (17)

As pessoas costumam falar sobre desempenho, leituras x gravações, chaves estrangeiras, etc., mas, na minha opinião, há outro recurso imprescindível para um mecanismo de armazenamento: atualizações atômicas.

Tente isto:

  1. Emita uma ATUALIZAÇÃO contra sua tabela MyISAM que leva 5 segundos.
  2. Enquanto o UPDATE estiver em andamento, digamos 2,5 segundos, pressione Ctrl-C para interrompê-lo.
  3. Observe os efeitos na mesa. Quantas linhas foram atualizadas? Quantos não foram atualizados? A tabela é legível ou foi corrompida quando você pressionou Ctrl-C?
  4. Tente o mesmo experimento com UPDATE em uma tabela InnoDB, interrompendo a consulta em andamento.
  5. Observe a tabela InnoDB. Zero linhas foram atualizadas. O InnoDB garantiu que você tem atualizações atômicas e, se a atualização completa não puder ser confirmada, ele reverterá a alteração inteira. Além disso, a tabela não está corrompida. Isso funciona mesmo se você usar o killall -9 mysqld para simular uma falha.

O desempenho é desejável, é claro, mas não perder dados deve prevalecer sobre isso.

Estou trabalhando em projetos que envolvem muitas gravações de banco de dados, eu diria ( 70% de inserções e 30% de leituras ). Essa proporção também inclui atualizações que considero serem uma só leitura e uma gravação. As leituras podem estar sujas (por exemplo, não preciso de 100% de informações precisas no momento da leitura).
A tarefa em questão fará mais de 1 milhão de transações de banco de dados por hora.

Eu li um monte de coisas na web sobre as diferenças entre MyISAM e InnoDB, e MyISAM parece ser a escolha óbvia para o banco de dados / tabelas em particular que eu usarei para esta tarefa. Pelo que pareço estar lendo, o InnoDB é bom se as transações forem necessárias, já que o bloqueio de nível de linha é suportado.

Alguém tem alguma experiência com este tipo de carga (ou superior)? MyISAM é o caminho a percorrer?


Eu discussed brevemente essa questão em uma tabela para que você possa concluir se deseja usar o InnoDB ou o MyISAM .

Aqui está uma pequena visão geral de qual mecanismo de armazenamento db você deve usar em qual situação:

                                                 MyISAM   InnoDB
----------------------------------------------------------------
Required full-text search                        Yes      5.6.4
----------------------------------------------------------------
Require transactions                                      Yes
----------------------------------------------------------------
Frequent select queries                          Yes      
----------------------------------------------------------------
Frequent insert, update, delete                           Yes
----------------------------------------------------------------
Row locking (multi processing on single table)            Yes
----------------------------------------------------------------
Relational base design                                    Yes

Para resumir:

Frequent reading, almost no writing   => MyISAM
Full-text search in MySQL <= 5.5      => MyISAM

Em todas as outras circunstâncias, o InnoDB é geralmente o melhor caminho a percorrer.


Não sou especialista em banco de dados e não falo por experiência. Contudo:

Tabelas MyISAM usam o bloqueio em nível de tabela . Com base nas suas estimativas de tráfego, você tem cerca de 200 gravações por segundo. Com o MyISAM, apenas um deles pode estar em progresso a qualquer momento . Você precisa ter certeza de que seu hardware pode acompanhar essas transações para evitar sobrecargas, ou seja, uma única consulta pode demorar mais de 5 ms.

Isso sugere que você precisaria de um mecanismo de armazenamento que suporte bloqueio em nível de linha, ou seja, InnoDB.

Por outro lado, deve ser bastante trivial escrever alguns scripts simples para simular a carga com cada mecanismo de armazenamento e comparar os resultados.


O InnoDB oferece:

ACID transactions
row-level locking
foreign key constraints
automatic crash recovery
table compression (read/write)
spatial data types (no spatial indexes)

No InnoDB, todos os dados em uma linha, exceto TEXT e BLOB, podem ocupar no máximo 8.000 bytes. Nenhuma indexação de texto completo está disponível para o InnoDB. No InnoDB, o COUNT (*) s (quando WHERE, GROUP BY ou JOIN não é usado) é executado mais devagar que no MyISAM porque a contagem de linhas não é armazenada internamente. O InnoDB armazena dados e índices em um arquivo. O InnoDB usa um buffer pool para armazenar dados e índices em cache.

MyISAM oferece:

fast COUNT(*)s (when WHERE, GROUP BY, or JOIN is not used)
full text indexing
smaller disk footprint
very high table compression (read only)
spatial data types and indexes (R-tree)

MyISAM possui bloqueio no nível da tabela, mas não possui bloqueio no nível da linha. Nenhuma transação Não há recuperação automática de falhas, mas oferece funcionalidade de tabela de reparo. Nenhuma restrição de chave estrangeira. Tabelas MyISAM são geralmente mais compactas em tamanho no disco quando comparadas a tabelas InnoDB. As tabelas MyISAM podem ser ainda mais reduzidas em tamanho, comprimindo com myisampack, se necessário, mas tornam-se somente leitura. O MyISAM armazena índices em um arquivo e dados em outro. O MyISAM usa buffers de chaves para caching de índices e deixa o gerenciamento de cache de dados para o sistema operacional.

No geral, eu recomendaria o InnoDB para a maioria dos propósitos e o MyISAM apenas para usos especializados. O InnoDB agora é o mecanismo padrão nas novas versões do MySQL.


Para uma carga com mais gravações e leituras, você se beneficiará do InnoDB. Como o InnoDB fornece bloqueio de linha em vez de bloqueio de tabela, seus SELECT podem ser simultâneos, não apenas uns com os outros, mas também com muitos INSERT s. No entanto, a menos que você pretenda usar transações SQL, defina o flush de confirmação do InnoDB como 2 ( innodb_flush_log_at_trx_commit ). Isso lhe dá de volta muito desempenho bruto que você perderia ao mover tabelas do MyISAM para o InnoDB.

Além disso, considere adicionar replicação. Isto dá-lhe alguma escala de leitura e desde que você declarou que suas leituras não precisam estar atualizadas, você pode deixar a replicação ficar um pouco para trás. Apenas certifique-se de que ele pode alcançar tudo menos o tráfego mais pesado ou sempre estará atrasado e nunca o alcançará. Se você seguir esse caminho, no entanto, eu recomendo fortemente que você isole a leitura dos escravos e o gerenciamento de retardo de replicação para seu manipulador de banco de dados. É muito mais simples se o código da aplicação não souber disso.

Finalmente, esteja ciente das diferentes cargas de tabela. Você não terá a mesma proporção de leitura / gravação em todas as tabelas. Algumas tabelas menores, com quase 100% de leituras, poderiam ficar no MyISAM. Da mesma forma, se você tiver algumas tabelas próximas a 100%, poderá se beneficiar de INSERT DELAYED , mas isso é suportado apenas no MyISAM (a cláusula DELAYED é ignorada para uma tabela InnoDB).

Mas benchmark para ter certeza.


Um pouco atrasado para o jogo ... mas aqui está um post bastante abrangente que escrevi há alguns meses , detalhando as principais diferenças entre o MYISAM e o InnoDB. Pegue uma xícara de chá (e talvez um biscoito) e aproveite.

A principal diferença entre MyISAM e InnoDB está na integridade e transações referenciais. Há também outras diferenças, como bloqueios, reversões e pesquisas de texto completo.

Integridade referencial

A integridade referencial garante que os relacionamentos entre as tabelas permaneçam consistentes. Mais especificamente, isso significa que quando uma tabela (por exemplo, Listings) tem uma chave estrangeira (por exemplo, Product ID) apontando para uma tabela diferente (por exemplo Products), quando atualizações ou exclusões ocorrem na tabela apontada, essas alterações são em cascata para o link mesa. Em nosso exemplo, se um produto for renomeado, as chaves externas da tabela de vinculação também serão atualizadas; se um produto for excluído da tabela "Produtos", todas as listagens que apontarem para a entrada excluída também serão excluídas. Além disso, qualquer nova listagem deve ter essa chave estrangeira apontando para uma entrada existente válida.

O InnoDB é um SGBD relacional (RDBMS) e, portanto, tem integridade referencial, enquanto o MyISAM não.

Transações e Atomicidade

Os dados em uma tabela são gerenciados usando instruções DML (Data Manipulation Language), como SELECT, INSERT, UPDATE e DELETE. Um grupo de transações duas ou mais instruções DML juntas em uma única unidade de trabalho, portanto, a unidade inteira é aplicada ou nenhuma delas é.

MyISAM não suporta transações enquanto o InnoDB faz.

Se uma operação for interrompida durante o uso de uma tabela MyISAM, a operação será abortada imediatamente e as linhas (ou até mesmo os dados dentro de cada linha) afetadas permanecerão afetadas, mesmo que a operação não tenha sido concluída.

Se uma operação é interrompida durante o uso de uma tabela InnoDB, porque ela usa transações, que tem atomicidade, qualquer transação que não foi concluída não terá efeito, uma vez que nenhuma confirmação é feita.

Bloqueio de tabela vs Bloqueio de linha

Quando uma consulta é executada em uma tabela MyISAM, toda a tabela em que está consultando será bloqueada. Isso significa que as consultas subseqüentes serão executadas somente após o término da atual. Se você estiver lendo uma tabela grande e / ou houver operações freqüentes de leitura e gravação, isso pode significar um enorme acúmulo de consultas.

Quando uma consulta é executada em uma tabela InnoDB, apenas as linhas envolvidas estão bloqueadas, o resto da tabela permanece disponível para as operações CRUD. Isso significa que as consultas podem ser executadas simultaneamente na mesma tabela, desde que não usem a mesma linha.

Esse recurso no InnoDB é conhecido como simultaneidade. Por maior que seja a simultaneidade, há uma grande desvantagem que se aplica a um intervalo selecionado de tabelas, em que há uma sobrecarga na alternância entre encadeamentos do kernel e você deve definir um limite nos encadeamentos do kernel para evitar que o servidor pare. .

Transações e Reversões

Quando você executa uma operação no MyISAM, as mudanças são definidas; no InnoDB, essas mudanças podem ser revertidas. Os comandos mais comuns usados ​​para controlar transações são COMMIT, ROLLBACK e SAVEPOINT. 1. COMMIT - você pode escrever múltiplas operações DML, mas as mudanças só serão salvas quando um COMMIT for feito 2. ROLLBACK - você pode descartar qualquer operação que ainda não tenha sido confirmada ainda 3. SAVEPOINT - define um ponto na lista de operações para as quais uma operação ROLLBACK pode reverter para

Confiabilidade

O MyISAM não oferece integridade de dados - Falhas de hardware, desligamentos não limpos e operações canceladas podem corromper os dados. Isso exigiria reparo completo ou reconstruções dos índices e tabelas.

O InnoDB, por outro lado, usa um log transacional, um buffer de gravação dupla e soma de verificação e validação automáticas para evitar corrupção. Antes do InnoDB fazer quaisquer alterações, ele registra os dados antes das transações em um arquivo de espaço de tabela do sistema chamado ibdata1. Se houver uma falha, o InnoDB poderá recuperar automaticamente a reprodução desses logs.

Indexação FULLTEXT

O InnoDB não suporta indexação FULLTEXT até a versão 5.6.4 do MySQL. A partir da escrita deste post, a versão MySQL de muitos provedores de hospedagem compartilhada ainda está abaixo de 5.6.4, o que significa que a indexação FULLTEXT não é suportada para tabelas InnoDB.

No entanto, este não é um motivo válido para usar o MyISAM. É melhor mudar para um provedor de hospedagem que ofereça suporte a versões atualizadas do MySQL. Não que uma tabela MyISAM que use indexação FULLTEXT não possa ser convertida em uma tabela InnoDB.

Conclusão

Em conclusão, o InnoDB deve ser seu mecanismo de armazenamento padrão escolhido. Escolha MyISAM ou outros tipos de dados quando eles atendem a uma necessidade específica.


A pergunta e a maioria das respostas estão desatualizadas .

Sim, é um antigo conto de esposas que o MyISAM é mais rápido que o InnoDB. observe a data da pergunta: 2008; agora é quase uma década depois. O InnoDB deu passos significativos no desempenho desde então.

O gráfico dramático foi para o caso em que MyISAM vence: COUNT(*) sem uma WHEREcláusula. Mas isso é realmente o que você gasta seu tempo fazendo?

Se você executar o teste de simultaneidade , é muito provável que o InnoDB ganhe, mesmo contraMEMORY .

Se você fizer alguma gravação enquanto benchmarking SELECTs, MyISAM e MEMORYprovavelmente perderá por causa do bloqueio em nível de tabela.

Na verdade, a Oracle tem tanta certeza de que o InnoDB é melhor que todos eles, além de remover o MyISAM da 8.0.

A pergunta foi escrita no início dos dias de 5.1. Desde então, essas versões principais foram marcadas como "Disponibilidade geral":

  • 2010: 5,5 (0,8 em dezembro)
  • 2013: 5.6 (.10 em fev.)
  • 2015: 5,7 (0,9 em outubro)
  • 2018: 8,0 (0,11 em abril)

Resumindo: Não use MyISAM


Por favor, note que a minha educação formal e experiência é com a Oracle, enquanto o meu trabalho com o MySQL tem sido inteiramente pessoal e no meu próprio tempo, então se eu disser coisas que são verdadeiras para a Oracle, mas não são verdadeiras para o MySQL, peço desculpas. Enquanto os dois sistemas compartilham muito, a teoria / álgebra relacional é a mesma, e os bancos de dados relacionais ainda são bancos de dados relacionais, ainda há muitas diferenças !!

Eu particularmente gosto (assim como o bloqueio em nível de linha) que o InnoDB é baseado em transação, o que significa que você pode estar atualizando / inserindo / criando / alterando / descartando / etc várias vezes para uma "operação" de seu aplicativo da web. O problema que surge é que, se apenas algumas dessas alterações / operações acabarem sendo confirmadas, mas outras não, você irá, na maioria das vezes (dependendo do design específico do banco de dados), acabar com um banco de dados com estrutura / dados conflitantes.

Nota: Com o Oracle, as instruções create / alter / drop são chamadas de instruções "DDL" (Data Definition) e implicitamente acionam um commit. As instruções de inserção / atualização / exclusão, chamadas "DML" (Manipulação de dados), não são confirmadas automaticamente, mas somente quando uma DDL, confirmação ou saída / saída é executada (ou se você definir sua sessão como "confirmação automática" ou se o seu cliente se comprometer automaticamente). É imperativo estar ciente disso ao trabalhar com o Oracle, mas não tenho certeza de como o MySQL lida com os dois tipos de instruções. Por causa disso, quero deixar claro que não tenho certeza disso quando se trata do MySQL; somente com o Oracle.

Um exemplo de quando os mecanismos baseados em transações se destacam:

Digamos que você ou você esteja em uma página da web para se inscrever para participar de um evento gratuito, e um dos principais objetivos do sistema é permitir que até 100 pessoas se inscrevam, já que esse é o limite do assento para o evento. Depois que 100 inscrições forem alcançadas, o sistema desativará inscrições adicionais, pelo menos até que outras pessoas cancelem.

Nesse caso, pode haver uma tabela para convidados (nome, telefone, email, etc.) e uma segunda tabela que rastreia o número de convidados que se inscreveram. Assim, temos duas operações para uma "transação". Agora, suponha que depois que as informações do convidado sejam adicionadas à tabela GUESTS, haja uma perda de conexão ou um erro com o mesmo impacto. A tabela GUESTS foi atualizada (inserida em), mas a conexão foi perdida antes que os "lugares disponíveis" pudessem ser atualizados.

Agora, temos um convidado adicionado à tabela de convidados, mas o número de assentos disponíveis está incorreto (por exemplo, o valor é 85 quando, na verdade, é 84).

É claro que há muitas maneiras de lidar com isso, como controlar assentos disponíveis com "menos 100 números de linhas na tabela de convidados" ou algum código que verifique se as informações são consistentes, etc .... Mas com um banco de dados baseado em transações motor como InnoDB, TODAS as operações estão comprometidas, ou NENHUM deles são. Isso pode ser útil em muitos casos, mas, como eu disse, não é a ÚNICA maneira de ser seguro, não (uma boa maneira, no entanto, tratada pelo banco de dados, não pelo programador / roteirista).

Isso é tudo "baseado em transação" essencialmente significa neste contexto, a menos que eu esteja faltando alguma coisa - que toda a transação tenha sucesso como deveria, ou nada é mudado, desde que fazer apenas mudanças parciais poderia fazer um menor para a bagunça SEVERA do banco de dados, talvez até corrompê-lo ...

Mas vou dizer mais uma vez, não é a única maneira de evitar fazer uma bagunça. Mas é um dos métodos que o mecanismo em si manipula, deixando você codificar / script apenas precisando se preocupar com "a transação foi bem-sucedida ou não, e o que eu faço se não (como tentar novamente)", em vez de manualmente escrevendo código para verificá-lo "manualmente" de fora do banco de dados, e fazendo muito mais trabalho para tais eventos.

Por fim, uma observação sobre bloqueio de tabela versus bloqueio de linha:

ISENÇÃO DE RESPONSABILIDADE: Eu posso estar errado em tudo o que se segue em relação ao MySQL, e as situações hipotéticas / exemplo são coisas para se investigar, mas posso estar errado no que exatamente é possível causar corrupção no MySQL. Os exemplos são no entanto muito reais na programação geral, mesmo que o MySQL tenha mais mecanismos para evitar tais coisas ...

De qualquer forma, estou bastante confiante em concordar com aqueles que argumentam que quantas conexões são permitidas em um momento que não trabalhar em torno de uma tabela bloqueada. Na verdade, várias conexões são o ponto inteiro de bloquear uma mesa !! Para que outros processos / usuários / aplicativos não consigam corromper o banco de dados fazendo alterações ao mesmo tempo.

Como duas ou mais conexões trabalhando na mesma linha fazem um dia realmente ruim para você? Suponha que há dois processos que desejam / precisam atualizar o mesmo valor na mesma linha, digamos porque a linha é um registro de um passeio de ônibus e cada um dos dois processos simultaneamente deseja atualizar os "cavaleiros" ou "disponíveis" campo como "o valor atual mais 1."

Vamos fazer isso hipoteticamente, passo a passo:

  1. O processo um lê o valor atual, digamos que está vazio, portanto, '0' até agora.
  2. O processo dois também lê o valor atual, que ainda é 0.
  3. Processo um escreve (atual + 1) que é 1.
  4. O processo dois deve ser escrito 2, mas como leu o valor atual antes do processo um, escreve o novo valor, ele também escreve 1 na tabela.

Eu não estou certo de que duas conexões poderiam se misturar assim, ambas lendo antes da primeira escrita ... Mas se não, então eu ainda veria um problema com:

  1. O processo um lê o valor atual, que é 0.
  2. Processo um escreve (atual + 1), que é 1.
  3. O processo dois lê o valor atual agora. Mas enquanto processa um DID write (update), ele não comprometeu os dados, portanto, apenas esse mesmo processo pode ler o novo valor que ele atualizou, enquanto todos os outros vêem o valor mais antigo, até que haja um commit.

Além disso, pelo menos com bancos de dados Oracle, existem níveis de isolamento, que não vou perder nosso tempo tentando parafrasear. Aqui está um bom artigo sobre esse assunto, e cada nível de isolamento tem seus prós e contras, o que combinaria com a importância dos mecanismos baseados em transações em um banco de dados ...

Por último, pode haver diferentes salvaguardas no MyISAM, em vez de chaves estrangeiras e interação baseada em transações. Bem, por um lado, há o fato de que uma tabela inteira está bloqueada, o que torna menos provável que transações / FKs sejam necessárias .

E, infelizmente, se você está ciente desses problemas de simultaneidade, sim, você pode jogar menos seguro e apenas escrever seus aplicativos, configurar seus sistemas para que tais erros não sejam possíveis (seu código é então responsável, em vez do próprio banco de dados). No entanto, na minha opinião, eu diria que é sempre melhor usar tantas proteções quanto possível, programando defensivamente, e sempre ciente de que é impossível evitar completamente o erro humano. Isso acontece com todo mundo, e qualquer um que diga que é imune a ele deve estar mentindo, ou não fez mais do que escrever um script / aplicativo "Hello World". ;-)

Espero que ALGUNS sejam úteis para alguém, e mais ainda, espero que não tenha sido apenas um culpado de suposições e de ser um humano em erro! Minhas desculpas em caso afirmativo, mas os exemplos são bons para pensar, pesquisar o risco de, e assim por diante, mesmo que eles não sejam potenciais neste contexto específico.

Sinta-se à vontade para me corrigir, edite essa "resposta" e até mesmo vote nela. Por favor, tente melhorar, em vez de corrigir uma má suposição minha com outra. ;-)

Esta é a minha primeira resposta, então por favor, perdoem a duração devido a todas as isenções de responsabilidade, etc ... Eu só não quero parecer arrogante quando não estou absolutamente certo!


Confira também alguns substitutos do MySQL:

MariaDB

http://mariadb.org/

O MariaDB é um servidor de banco de dados que oferece funcionalidade de substituição direta para o MySQL. O MariaDB é construído por alguns dos autores originais do MySQL, com assistência da comunidade mais ampla de desenvolvedores de software livre e de código aberto. Além da funcionalidade principal do MySQL, o MariaDB oferece um rico conjunto de aprimoramentos de recursos, incluindo mecanismos de armazenamento alternativos, otimizações de servidor e correções.

Servidor Percona

https://launchpad.net/percona-server

Um substituto aprimorado para o MySQL, com melhor desempenho, diagnósticos aprimorados e recursos adicionais.


Eu sei que isso não será popular, mas aqui vai:

O myISAM carece de suporte para os fundamentos do banco de dados, como transações e integridade referencial, que geralmente resultam em aplicativos problemáticos / com bugs. Você não pode aprender os fundamentos de design do banco de dados se eles não forem suportados pelo seu mecanismo de db.

Não usar integridade referencial ou transações no mundo do banco de dados é como não usar programação orientada a objetos no mundo do software.

O InnoDB existe agora, use isso! Mesmo os desenvolvedores do MySQL finalmente concordaram em mudar isso para o mecanismo padrão nas versões mais novas, apesar do myISAM ser o mecanismo original que era o padrão em todos os sistemas legados.

Não, não importa se você está lendo ou escrevendo ou quais considerações de desempenho você tem, usando myISAM pode resultar em uma variedade de problemas, como este que eu corri: Eu estava executando uma sincronização de banco de dados e ao mesmo tempo outra pessoa acessou um aplicativo que acessou uma tabela definida como myISAM. Devido à falta de suporte a transações e à confiabilidade geralmente baixa desse mecanismo, isso causou o crash do banco de dados inteiro e eu tive que reiniciar manualmente o mysql!

Nos últimos 15 anos de desenvolvimento, usei muitos bancos de dados e mecanismos. myISAM caiu sobre mim uma dúzia de vezes durante este período, outros bancos de dados, apenas uma vez! E isso foi um banco de dados Microsoft microsoft, onde alguns desenvolvedores escreveram código CLR defeituoso (common language runtime - basicamente código C # que executa dentro do banco de dados), a propósito, não foi exatamente a falha do mecanismo de banco de dados.

Concordo com as outras respostas que dizem que aplicativos de alta disponibilidade e alta qualidade não devem usar myISAM, pois não funcionarão, não serão robustos ou estáveis ​​o suficiente para resultar em uma experiência livre de frustrações. Veja a resposta de Bill Karwin para mais detalhes.

PS Tenho que adorar quando fanboys myISAM downvotar, mas não posso dizer qual parte desta resposta está incorreta.


Resumindo, o InnoDB é bom se você estiver trabalhando em algo que precise de um banco de dados confiável que possa lidar com muitas instruções INSERT e UPDATE.

e, MyISAM é bom se você precisa de um banco de dados que estará recebendo muitas instruções de leitura (SELECT) ao invés de escrever (INSERIR e ATUALIZAR), considerando sua desvantagem no bloqueio de tabela.

você pode querer dar uma olhada;
Prós e contras do InnoDB
Prós e contras do MyISAM


Se é 70% insere e 30% lê, então é mais como no lado do InnoDB.


myisam é um NOGO para esse tipo de carga de trabalho (alta simultaneidade escreve), eu não tenho tanta experiência com innodb (testei 3 vezes e encontrei em cada caso que o desempenho foi ruim, mas já faz um tempo desde o último teste) se você não é forçado a executar o mysql, considere dar uma chance ao postgres, pois ele lida com gravações simultâneas MUITO melhor



Eu tentei executar a inserção de dados aleatórios em tabelas MyISAM e InnoDB. O resultado foi bastante chocante. O MyISAM precisou de alguns segundos a menos para inserir 1 milhão de linhas do que o InnoDB por apenas 10 mil!


Na minha experiência, MyISAM foi uma escolha melhor, desde que você não faça DELETEs, UPDATEs, um monte de INSERTs únicos, transações e indexação de texto completo. Aliás, CHECK TABLE é horrível. À medida que a tabela fica mais velha em termos do número de linhas, você não sabe quando terminará.


Se você usar MyISAM, você não vai fazer quaisquer transações por hora, a menos que você considere cada instrução DML para ser uma transação (que em qualquer caso, não será durável ou atômica no caso de um acidente).

Portanto, eu acho que você tem que usar o InnoDB.

300 transações por segundo soam bastante. Se você realmente precisar que essas transações sejam duráveis ​​em caso de falta de energia, certifique-se de que seu subsistema de E / S possa manipular facilmente essas muitas gravações por segundo. Você precisará de pelo menos um controlador RAID com cache suportado por bateria.

Se você aguentar um pouco de durabilidade, você pode usar o InnoDB com o innodb_flush_log_at_trx_commit configurado como 0 ou 2 (consulte os documentos para detalhes), você pode melhorar o desempenho.

Há vários patches que podem aumentar a concorrência do Google e de outras empresas. Isso pode ser interessante se você ainda não conseguir obter desempenho suficiente sem eles.





myisam