Bancos de dados comparados
MySQL: o banco de dados padrão, ainda ganhando
MySQL é o banco de dados no qual a maior parte da web é executada, não porque seja empolgante, mas porque é previsível: o núcleo ACID do InnoDB, um modelo de replicação que todo administrador já tocou e um ecossistema de painéis, plug-ins e suposições de aplicativos construídos sobre ele. O trabalho sério está nos padrões de configuração, na disciplina de replicação e em saber onde a versão 8 realmente ganha sua complexidade.
Pontos principais
- InnoDB é o mecanismo de armazenamento que importa: chaves primárias em cluster, bloqueio de linha e recuperação de refazer à prova de falhas; os artigos legados do MyISAM que recomendam trocas de mecanismo geralmente são anteriores à realidade de que uma pilha MySQL moderna é 99% InnoDB e mais feliz por isso.
- O MySQL 8 ganhou sua atualização com recursos reais: funções de janela, CTEs, EXPLAIN FORMAT=TREE aprimorado, manipulação de JSON classe Hermes via JSON_TABLE; os fluxos que baseavam o marketing de recursos dos forks MariaDB diminuíram consideravelmente.
- A replicação é onde as carreiras são feitas ou interrompidas: as configurações baseadas em GTID tornam a topologia (cadeia, multi-fonte) gerenciável, semi-sincronizada como um compromisso entre desempenho e durabilidade, e o atraso da réplica de leitura deve ser medido e não assumido (verificações no estilo pt-heartbeat ou latência baseada em performance_schema).
- O trabalho de desempenho começa com o log de consulta lento mais performance_schema: resumos de instruções, uso de índice e indexação do esquema primeiro superam cada lista mágica de parâmetros my.cnf; o dimensionamento do buffer pool versus o conjunto de trabalho é o verdadeiro botão que importa.
- Backups que restauram: fluxos de trabalho baseados em dump (mysqldump --single-transaction) para pequenas propriedades, instantâneos físicos (classe Percona xtrabackup) para velocidade e recuperação pontual sempre testada em relação a um cronograma de interrupção real, não a uma estrutura de documentação.
- Onde o status padrão do MySQL continua vencendo: os ecossistemas de aplicativos o assumem, os painéis o enviam (muitas vezes trocados por MariaDB), os operadores de nuvem o fornecem barato e os ecossistemas de plug-ins CMS (especialmente WordPress) testam-no primeiro; permanecer no padrão significa permanecer testado.
Nota de campo
O melhor trabalho de desempenho do MySQL que já vi não foi uma maratona de ajuste de configuração: foi um desenvolvedor excluindo três índices que lutaram contra uma tabela OLTP pela taxa de transferência de gravação. O cancelamento do benchmarking começa em resumos lentos de consultas, não em postagens de blog.
Perguntas frequentes
MySQL 8 ou MariaDB para um novo projeto?
Novos projetos sem restrições de ecossistema: MariaDB é um ótimo padrão, mas o MySQL 8 tem o ecossistema do fornecedor, patches de segurança e equipamentos de replicação. Compare os recursos que você realmente precisa, leia nosso artigo mysql-vs-postgresql para a questão relacional.
A mudança do MySQL existente para MariaDB requer alterações?
Downgrades em versões de formato binário são a vantagem: o dicionário de dados do MySQL 8 não é lido pelo MariaDB. A migração lógica (despejo/carregamento) funciona, a substituição do plugin precisa de inventário antes do compromisso.
Replicação semi-sincronizada: vale a pena a latência?
Reduz a perda silenciosa de dados de failover; a regra clássica é uma das duas opções de consistência/desempenho com async como linha de base. Para a maioria das cargas de trabalho congestionadas, a resposta certa é semissincronização mais failover testado, e não sincronização completa.
Como faço para impedir que um único site lento mate a caixa?
Recursos por usuário (CloudLinux db_governor em pilhas compartilhadas, limitação de consulta de proxy na frente) mais disciplina de consulta lenta; o próprio banco de dados não tem cinto de segurança, a menos que o ambiente lhe forneça um.
Como a Kinetikatech ajuda com bancos de dados comparados
Já resolvemos isto centenas de vezes: Escolhas de mecanismo de banco de dados para hospedar cargas de trabalho, comparadas em garantias de correção, peso operacional e custo real: mecanismos incorporados em relação a servidores, MySQL em relação a PostgreSQL, SQL em relação a armazenamentos de documentos, além do estudo de caso legado que continua voltando. Com Gestão de servidores e Otimização de velocidade, você tem o ciclo completo: avaliamos, implementamos, monitoramos 24 horas e respondemos em 30 minutos quando importa.