Início / dba / Perguntas / 177569
Accepted
Mannoj
Asked: 2017-06-29 23:03:58 +0800 CST

O Mysql ACID é compatível?

  • 772

O Mysql não é compatível com ACID de acordo com o Postgresql? Em alguns blogs, vejo que o Mysql não é compatível com ACID. Quão verdadeiro é isso?

Não vamos considerar a replicação aqui, vamos considerar um autônomo e quão eficiente é o Mysql ACID?

No meu entendimento para Mysql-ACID.

A - Atomicidade (conjunto de transações devem ser todas confirmadas, se uma falhar, ela deve ser revertida. Sim significa que todas estão confirmadas, não significa que mesmo uma falhando deve ser revertida).

Os recursos do IE que suportam no Mysql são.

  • iniciar Transação; ..... comprometer-se ;
  • auto_commit=1;

C - Consistência.

(PK,FK,UK,NOT-NULL). Adere a Relações e restrições para Bancos de Dados. A instância de uma chave pai pode ser excluída somente quando sua chave filha é removida.

I - Isolamento. Isolamento entre usuários e seu estado de confirmação.

Ler Repetível Ler Não Confirmado Ler Comprometido Serializado

D - Durabilidade. No caso de falha do banco de dados, o innodb recupera o banco de dados aplicando a transação confirmada do arquivo iblog e descarta a transação não confirmada.

Clique aqui para ver a fonte desta pergunta. - É porque o blog foi criado em 2001?

ATUALIZAÇÃO Jun-30-2017: De acordo com a resposta "Evan Carroll" e eu testei pessoalmente o experimento do blog em 5.7.18-enterprise. Os resultados obtidos do experimento parecem ser Mysql não é compatível com ACID.

mysql postgresql

3 respostas

  1. Se você usa o InnoDB ou um mecanismo de armazenamento semelhante, ele deve ser compatível com ACID (ref: https://en.wikipedia.org/wiki/InnoDB ). myISAM, o padrão antigo e ainda muito usado, definitivamente não é compatível com ACID. Se você misturar os dois (você pode descobrir que tipos de tabela mais simples têm melhor desempenho e são aceitáveis ​​para dados voláteis que podem e serão reproduzidos novamente, como tabelas de preparo para processos ETL), sua solução não será totalmente compatível.

    Uma grande ressalva com a conformidade ACID é que, por motivos de desempenho, a maioria dos bancos de dados usa um nível de isolamento que não garante a parte "I" - isso está dentro das especificações ANSI SQL. Para oferecer isolamento adequado, você precisa garantir que as transações sejam serializáveis, um nível de isolamento que alguns bancos de dados nem suportam. Por exemplo, MySQL+InnoDB padroniza para "leitura repetível", enquanto o MS SQL Server padroniza para "leitura confirmada" um pouco mais estrita, ambos oferecem "serializável", mas não é o padrão. Por que nem sempre é suportado e geralmente não é o padrão? Desempenho: um requisito de isolamento completo pode limitar significativamente a simultaneidade.

    Existem alguns bons artigos sobre o assunto. Por exemplo , http://www.bailis.org/blog/when-is-acid-acid-rarely/ é um lugar curto e informativo para começar com uma discussão interessante nos comentários.

    • 10
  2. Best Answer

    Não

    Eu não acho que permitir Phantom Writes em Repeatable Read satisfaça qualquer conformidade com ACID.

    Veja esta entrada de blog para obter mais informações.

    • 3

  3. Há muito debate sobre isso se o MySQL realmente e completamente segue as propriedades ACID, e todos têm sua própria opinião. De acordo com o doc do MySQL https://dev.mysql.com/doc/refman/5.6/en/mysql-acid.html

    MySQL com motores Innodb seguem de perto a propriedade ACID. Mas essa é a visão deles.

    Mas não devemos esquecer que com as novas versões, o MySQL melhorou muito e eu pessoalmente aprecio a Oracle por eles estarem otimizando de uma maneira muito boa. Portanto, a versão anterior pode não seguir o ACID, mas hoje é.

    No entanto, deixe-me tentar colocar todas as propriedades uma a uma, como o MySQL com o Innodb segue essas propriedades:

    1. Atomicity diz que ou reverte ou confirma a transação completa. De acordo com minha experiência, os mecanismos do Innodb fazem rollback sempre que ocorre alguma falha no meio da transação. Ele manipula armazenando os resultados de instruções transacionais (as páginas sujas ou linhas modificadas) em um buffer de gravação duplo (se habilitado) ou redo-logs ou logs binários (se habilitado) e gravando esses resultados de volta no disco, independentemente de a transação estar no estado preparado. Se não for, a transação será revertida. Apenas mate seu mysqld e reinicie-o e observe seu arquivo de log de erros.

    2. A consistência também foi seguida no Innodb, pois existem vários mecanismos de registro (buffers) que registram todas as alterações que ocorrem em seu banco de dados e nos ajudam a garantir que nenhuma inconsistência ocorra.

    3. Isolamento : O Innodb fornece vários bloqueios em nível de linha que evitam (se manipulados adequadamente) qualquer outro processo para adquirir bloqueio em recursos que já estão em uso por outro processo. e gravando esses resultados de volta no disco e no log binário do buffer somente quando a transação for confirmada.

    4. Durabilidade : De acordo com o MySQL DOC , o aspecto de durabilidade do modelo ACID envolve recursos de software MySQL interagindo com sua configuração de hardware específica. Devido às muitas possibilidades, dependendo dos recursos de sua CPU, rede e dispositivos de armazenamento, esse aspecto é o mais complicado para fornecer diretrizes concretas. (E essas diretrizes podem assumir a forma de comprar “novo hardware”.) . Por exemplo, o log binário garante a durabilidade em caso de qualquer falha.

    Deixe-me saber, se isso te ajudar :)

    • 1

relate perguntas