Quais são as vantagens e desvantagens do MySQL e quando ele é uma boa escolha?
O MySQL é um sistema de gerenciamento de banco de dados relacional que pode ser usado para serviços web típicos e processamento de transações online (OLTP), especialmente ao usar o mecanismo de armazenamento InnoDB e seus recursos, como transações, bloqueio em nível de linha e leituras consistentes. Por outro lado, a replicação de leitura é assíncrona por padrão, e configurações de alta disponibilidade, consultas complexas e particionamento têm restrições de projeto e operação. Suas vantagens tornam-se vantagens reais apenas quando se adequam à carga de trabalho e às capacidades operacionais da equipe. dev.mysql.com dev.mysql.com
Ao avaliar o MySQL, é mais preciso considerar como os dados são lidos e gravados, o que deve ser garantido durante falhas e quão complexo o esquema se tornará do que simplesmente perguntar se ele é um “banco de dados rápido”. A discussão a seguir segue o escopo da documentação oficial do MySQL 8.4. O comportamento real pode variar conforme a versão, o mecanismo de armazenamento, a configuração e a topologia de replicação. dev.mysql.com
Que tipo de banco de dados é o MySQL?
Um banco de dados relacional armazena dados em tabelas compostas por linhas e colunas e usa a linguagem de consulta SQL para gerenciar relações entre tabelas. Por exemplo, uma loja online pode usar tabelas como customers, orders e order_items para gerenciar relações entre clientes, pedidos e produtos solicitados. Muitos casos exigem que diversas alterações sejam agrupadas em uma única operação, como criar um pedido, reduzir o estoque e registrar o status do pagamento.
Os mecanismos de armazenamento são importantes no MySQL. Um mecanismo de armazenamento é um componente responsável pela forma como as tabelas são armazenadas, bloqueadas e recuperadas. Em especial, o InnoDB é o mecanismo de armazenamento padrão do MySQL e fornece transações ACID, commits e rollbacks, recuperação após falhas, bloqueio em nível de linha, controle de concorrência multiversão (MVCC) e chaves estrangeiras. Portanto, a confiabilidade transacional comumente associada ao MySQL geralmente se refere ao MySQL que usa tabelas InnoDB configuradas corretamente. dev.mysql.com
ACID é um termo coletivo para as propriedades esperadas das transações. Atomicidade significa que uma operação inteira é concluída com sucesso ou cancelada. Consistência significa que as regras de dados definidas são mantidas. Isolamento controla os efeitos que operações executadas simultaneamente exercem umas sobre as outras, enquanto durabilidade significa que resultados confirmados devem sobreviver a falhas. As características ACID do MySQL também são afetadas pelo mecanismo, pela configuração, pelo hardware e pelos procedimentos operacionais; portanto, o nome por si só não deve ser entendido como uma solução automática para todos os cenários de falha. dev.mysql.com
Por que as transações e a concorrência do InnoDB são uma vantagem?
OLTP refere-se a cargas de trabalho com solicitações frequentes e relativamente curtas, como receber pedidos, atualizar informações de membros ou alterar o status de pagamento. Nesse ambiente, muitos usuários podem modificar simultaneamente os mesmos tipos de dados; por isso, é importante agrupar alterações de dados com segurança e manter o escopo dos conflitos o menor possível.
Como o InnoDB fornece commits, rollbacks e recuperação após falhas, uma aplicação pode ser configurada para reverter uma transação se uma etapa falhar, por exemplo, ao criar um pedido e reduzir o estoque. O bloqueio em nível de linha bloqueia linhas específicas conforme necessário e pode ser mais favorável ao trabalho concorrente do que bloquear amplamente uma tabela inteira. No entanto, esperas e conflitos não desaparecem quando várias operações disputam frequentemente as mesmas linhas ou intervalos de dados adjacentes. dev.mysql.com
O MVCC fornece leituras consistentes usando múltiplas versões dos dados. Isso não significa simplesmente que leituras e gravações nunca interferem umas nas outras. Os resultados observados e o comportamento de bloqueio podem diferir dependendo do nível de isolamento de uma transação, das instruções SQL executadas e do uso de leituras com bloqueio. Portanto, ao resolver problemas de concorrência, não verifique apenas o nome do mecanismo. Primeiro, defina nas regras de negócio quais leituras devem ver o valor mais recente e quais atualizações devem ser mutuamente exclusivas.
Uma chave estrangeira é uma restrição que ajuda a assegurar que um valor em uma tabela faça referência a uma linha existente em outra tabela. Por exemplo, ela pode garantir que o ID do cliente em um pedido aponte para um cliente real. Isso pode ajudar a reduzir referências inválidas, mas também significa que as regras de exclusão e atualização e a estrutura das tabelas devem ser projetadas cuidadosamente com antecedência. Se você planeja introduzir particionamento depois, também deve verificar as restrições de compatibilidade relacionadas a chaves estrangeiras. dev.mysql.com dev.mysql.com
Quais são as vantagens para ambientes de desenvolvimento e controle de acesso?
O MySQL fornece vários protocolos de cliente e APIs para C/C++, Java, PHP, Python, Ruby e outras linguagens. Aplicações que já usam essas linguagens e ferramentas, portanto, têm opções para construir uma camada de conexão, e pode ser relativamente simples estabelecer um caminho básico entre uma aplicação web e o banco de dados. No entanto, a existência de uma API para determinada linguagem não garante, por si só, que o pool de conexões, as novas tentativas após erros, os conjuntos de caracteres e o tratamento de fuso horário estejam configurados corretamente. A abordagem de acesso a dados da aplicação deve ser validada separadamente. dev.mysql.com
O sistema de privilégios também faz parte do projeto operacional. O MySQL fornece privilégios nos níveis global, de banco de dados e de objeto, além de privilégios dinâmicos. Isso pode ser usado para separar funções: por exemplo, conceder a uma conta de aplicação somente as permissões de leitura e gravação necessárias para tabelas específicas, enquanto são usadas contas separadas para backup e tarefas administrativas. O princípio do menor privilégio é um princípio de projeto útil para limitar o impacto caso uma conta seja comprometida ou um programa contenha um erro. dev.mysql.com
No entanto, tornar os privilégios mais granulares não completa a segurança por si só. Na prática, você precisa gerenciar quais contas têm quais privilégios, se as contas de administrador e de aplicação estão separadas e qual processo governa as alterações de privilégios. Em outras palavras, os recursos de privilégios do MySQL fornecem mecanismos de controle, mas a responsabilidade de atribuí-los de acordo com as funções de negócio continua sendo da operação.
Que problemas os índices e o particionamento resolvem?
Um índice é uma estrutura de dados projetada para reduzir a necessidade de examinar uma tabela inteira a fim de encontrar as linhas desejadas. Por exemplo, se forem comuns as solicitações para encontrar um único pedido pelo número do pedido, um índice nessa coluna pode ajudar. Índices de múltiplas colunas podem ser úteis para consultas que usam várias colunas juntas como condições, mas a ordem das colunas e os predicados reais da consulta são importantes. O InnoDB suporta até 64 índices secundários por tabela e até 16 colunas por índice de múltiplas colunas. dev.mysql.com
No entanto, os índices não são automaticamente melhores quanto mais deles são criados. Índices consomem espaço de armazenamento e também precisam ser mantidos quando linhas são inseridas, atualizadas ou excluídas. O limite do número de índices suportados é um limite técnico, não uma meta de projeto. A necessidade real de um índice que encurta um caminho de busca e o quanto ele aumenta a carga nos caminhos de gravação devem ser avaliados com base em consultas representativas e na distribuição dos dados.
Índices de strings também têm restrições físicas. O limite de prefixo de chave de índice do InnoDB geralmente é de 3.072 bytes, embora possa ser reduzido para 767 bytes dependendo do formato da linha. Se você tentar indexar strings longas usando um conjunto de caracteres com grande tamanho de armazenamento por caractere, como utf8mb4, esse limite poderá afetar o projeto do esquema. É especialmente importante distinguir que este é um limite baseado em bytes, não em contagem de caracteres. dev.mysql.com
O particionamento é um recurso que armazena uma tabela em várias partições de acordo com regras definidas. Se uma condição corresponder às regras de particionamento, a eliminação de partições pode excluir as partições que o MySQL não precisa pesquisar. Por exemplo, para uma tabela grande de histórico consultada por intervalo de datas, se a tabela for particionada por data, você pode considerar um projeto que reduza o intervalo-alvo de buscas em determinado período. dev.mysql.com
Isso não significa que toda tabela grande deva ser particionada. Se as condições usadas com frequência não corresponderem à chave de particionamento, a redução esperada dos dados-alvo talvez não ocorra. O particionamento também introduz regras adicionais para operações, projeto de chaves e restrições; por isso, é melhor primeiro comparar se o problema pode ser resolvido com índices mais simples e melhorias na consulta.
Quais restrições se aplicam ao particionamento e à pesquisa de texto completo?
No MySQL 8.4, o particionamento é suportado pelos mecanismos de armazenamento InnoDB e NDB. Uma tabela InnoDB particionada não pode ter chaves estrangeiras, nem ser o destino de referências de chave estrangeira de outra tabela. Além disso, toda coluna usada na chave de particionamento deve fazer parte de toda chave única, incluindo a chave primária. Essa condição pode alterar significativamente o modelo ao tentar particionar uma tabela central com muitas referências, como uma tabela de pedidos. dev.mysql.com
A pesquisa de texto completo é um recurso para pesquisar texto por palavras. O MySQL suporta pesquisa de texto completo com InnoDB e MyISAM, mas ela não é suportada em tabelas particionadas. Portanto, se você espera usar, na mesma tabela, tanto funcionalidade de pesquisa para documentos longos quanto particionamento para dados históricos em grande escala, deve verificar antecipadamente se essa combinação é possível. Adicionar um recurso mais tarde pode exigir dividir tabelas ou mudar a arquitetura de pesquisa. dev.mysql.com
Essas restrições não mostram simplesmente que o MySQL não tem recursos, mas que os recursos talvez não possam ser combinados de modo independente. Você pode verificar, um a um, a necessidade de chaves estrangeiras, chaves únicas, chaves de particionamento e pesquisa de texto completo. É mais seguro evitar decidir um esquema com base no benefício de apenas um recurso.
Como a replicação pode ser usada para escalar leituras e backups?
A replicação é uma arquitetura que envia alterações de um servidor para outro. Normalmente, um servidor de origem registra as alterações e servidores de réplica as aplicam. Distribuir algumas solicitações de leitura entre várias réplicas pode reduzir a carga de leitura da origem, e você também pode considerar transferir tarefas de backup ou análise para réplicas. dev.mysql.com
GTID é um método de tratar posições de replicação atribuindo um identificador a cada transação. A replicação baseada em GTID pode ajudar a reduzir o esforço de alinhar manualmente nomes e posições de arquivos de log binário. No entanto, estabelecer uma topologia de replicação é diferente de monitorar o atraso de replicação e operar procedimentos de recuperação. Você deve determinar qual servidor recebe gravações, quais servidores podem atender leituras e o que fazer quando ocorrer atraso. dev.mysql.com
A replicação padrão é assíncrona. Isso significa que, no instante em que um commit na origem é concluído, não há garantia de que todas as réplicas tenham aplicado a mesma alteração. Por exemplo, uma consulta direcionada a uma réplica imediatamente após um usuário alterar o endereço pode mostrar o endereço anterior. Isso pode ser entendido como um problema de consistência de leitura após gravação. Solicitações que devem ter os dados mais recentes precisam de uma política que as direcione à origem ou leve em conta o status de aplicação da réplica. dev.mysql.com
A replicação semissíncrona usa uma abordagem na qual a origem recebe confirmação de que uma réplica recebeu e registrou um evento de transação. Trata-se de uma alternativa à replicação assíncrona padrão, mas não significa que todos os requisitos se tornem totalmente síncronos. Ao discutir requisitos síncronos fortes, defina claramente o nível de consistência exigido, a faixa de latência aceitável e o comportamento em caso de falha; depois, considere também opções separadas, como NDB Cluster. dev.mysql.com
O Group Replication resolve automaticamente a alta disponibilidade?
Alta disponibilidade é o objetivo de configurar um sistema para que um serviço possa continuar quando parte de um servidor ou da rede falha. O Group Replication gerencia a associação ao grupo, elege automaticamente um primário no modo de primário único ou suporta configurações de múltiplos primários. Sua capacidade de formar uma topologia de alta disponibilidade quando combinado com InnoDB Cluster e MySQL Router é uma opção importante do MySQL. dev.mysql.com
No entanto, o consenso entre servidores de banco de dados e o failover de conexão da aplicação não são o mesmo problema. O Group Replication não inclui funcionalidade para transferir clientes que falharam para membros íntegros. As aplicações precisam de MySQL Router, um balanceador de carga, um conector ou middleware personalizado para determinar onde se conectar, e essa camada também deve ser operada considerando falhas, novas tentativas e atualizações de estado. dev.mysql.com
Portanto, quando você ouvir “failover automático”, faça pelo menos três perguntas separadas. Primeiro, um primário pode ser eleito? Segundo, novas conexões da aplicação são direcionadas a um servidor íntegro? Terceiro, quais resultados serão vistos por solicitações em andamento e por solicitações repetidas pelo usuário? A existência de um recurso para a primeira pergunta não garante automaticamente as outras duas.
Uma configuração de múltiplos primários também é difícil de entender simplesmente como uma opção para aumentar o desempenho de gravação. Quando gravações são permitidas a partir de vários locais, você também precisa projetar como modificações simultâneas dos mesmos dados serão evitadas ou tratadas no nível de negócio e quais regras o caminho de gravação da aplicação deverá seguir. Alta disponibilidade é uma preocupação operacional que inclui não apenas a seleção de recursos, mas também exercícios de falha, observabilidade e procedimentos de recuperação.
Por que consultas complexas podem aumentar a carga de ajuste?
O otimizador é um componente que escolhe o plano de execução estimado como tendo o menor custo entre várias formas de executar uma instrução SQL. Por exemplo, ele determina qual índice usar primeiro e a ordem em que as tabelas serão unidas. O otimizador baseado em custo do MySQL pode depender de estimativas quando as estatísticas são insuficientes; por isso, pode escolher um plano diferente do esperado por uma pessoa. dev.mysql.com
À medida que o número de tabelas unidas aumenta, o número de planos de execução candidatos pode crescer exponencialmente. Nesse caso, não apenas a recuperação dos dados em si, mas também o tempo de otimização necessário para explorar planos adequados pode se tornar um gargalo. Portanto, em sistemas que executam frequentemente consultas analíticas complexas ou muitas junções, é difícil determinar a adequação apenas com base em a SQL poder ser executada sintaticamente. Os testes devem usar distribuições reais de dados e condições representativas. dev.mysql.com
EXPLAIN é uma ferramenta para verificar o plano de execução selecionado para uma consulta. Quando os resultados são lentos, primeiro inspecione os predicados, as condições de junção, os índices usados e as contagens estimadas de linhas. Se necessário, você pode atualizar estatísticas ou ajustar índices e a estrutura da consulta. Dicas de índice e recursos de controle do otimizador também estão disponíveis, mas abordagens que forçam um plano específico devem ser verificadas continuamente para garantir que permaneçam válidas após alterações nos dados. dev.mysql.com dev.mysql.com
Isso não significa que análises complexas não possam ser realizadas no MySQL. No entanto, se junções de várias tabelas em grande escala e consultas analíticas forem a carga de trabalho central, é realista comparar antecipadamente quanto tempo você pode dedicar ao ajuste, se as análises devem ser transferidas para réplicas e se deve ser adicionado um sistema analítico dedicado. Por outro lado, essa carga pode ser relativamente menor em um serviço composto principalmente por transações curtas e previsíveis.
Quando você deve ter cautela com rotinas armazenadas?
Rotinas armazenadas são procedimentos ou funções armazenados e executados no servidor de banco de dados. Elas podem manter algumas regras de processamento de dados próximas ao banco de dados, mas funções armazenadas que podem ser usadas em instruções SQL têm restrições. Por exemplo, uma função armazenada não pode usar uma instrução que retorna um conjunto de resultados. Uma função que calcula um único valor de retorno e uma operação de consulta que retorna várias linhas têm finalidades e padrões de uso diferentes. dev.mysql.com dev.mysql.com
O determinismo das rotinas armazenadas também importa em ambientes de replicação. Determinístico significa produzir o mesmo resultado para a mesma entrada. Rotinas não determinísticas ou dependentes do tempo que variam conforme a hora ou o estado do ambiente podem criar problemas de reprodutibilidade dependendo do método de replicação, exigindo cuidado especial com a replicação baseada em instruções. Ao colocar lógica de negócio no banco de dados, você também deve revisar se essa lógica pode produzir o mesmo resultado durante a replicação e a recuperação após falhas. dev.mysql.com
A decisão de usar rotinas armazenadas tem menos relação com a existência de um recurso do que com o local onde deve residir a responsabilidade por alterações, testes e implantação. Quando as regras são divididas entre o código da aplicação e as rotinas do banco de dados, o rastreamento e os testes podem se tornar mais complexos. Por outro lado, elas podem ser úteis para regras simples próximas à integridade dos dados. A pergunta principal é se a equipe consegue entender e gerenciar onde essas regras são executadas e seu impacto na replicação.
Quando o MySQL é uma boa escolha e quando você deve ter cautela?
A tabela a seguir não é uma classificação de produtos. Ela é uma perspectiva para verificar a adequação entre requisitos e recursos.
| Situação | O que você pode considerar com o MySQL | Condições a verificar em conjunto |
|---|---|---|
| Serviços web gerais e processamento de pedidos ou cadastros de membros | Você pode usar transações InnoDB, bloqueio em nível de linha, MVCC e chaves estrangeiras. | Os limites das transações e as regras de atualização concorrente devem ser projetados. |
| Serviços com muitas leituras | A replicação de origem para réplicas pode separar a carga de leitura, backup e análise. | Você precisa de políticas para atraso de réplica e leituras atuais. |
| Serviços que precisam de uma configuração tolerante a falhas | Você pode considerar uma topologia que combine Group Replication, Router e componentes relacionados. | Failover de conexão, novas tentativas e procedimentos de falha devem ser operados separadamente. |
| Consultas de histórico extenso por intervalo de datas | A eliminação de partições pode reduzir as partições-alvo dependendo da condição. | Verifique primeiro as restrições de chave estrangeira, chave única e pesquisa de texto completo. |
| Cargas de trabalho focadas em análise que unem muitas tabelas | Você pode usar execução SQL e recursos de controle de índices e do otimizador. | Avalie a validação do plano de execução e o custo do ajuste contínuo. |
As três primeiras linhas da tabela baseiam-se nos recursos oficiais do InnoDB, da replicação e do Group Replication. As duas últimas linhas também refletem o comportamento e as restrições do particionamento e do otimizador. dev.mysql.com dev.mysql.com dev.mysql.com dev.mysql.com dev.mysql.com
Em particular, se consistência forte entre várias regiões ou failover ininterrupto for um requisito central, você não deve tomar uma decisão apenas com base na replicação assíncrona padrão. Especifique os requisitos de atualidade dos dados, a latência aceitável, se as gravações continuam possíveis durante falhas e o caminho de failover da aplicação; depois, compare Group Replication, NDB Cluster ou outras opções distribuídas. Por outro lado, se você quiser processar de forma confiável transações típicas de leitura e gravação em uma única área de serviço e distribuir leituras para réplicas conforme necessário, a combinação de recursos do MySQL pode ser um ponto de partida prático. dev.mysql.com dev.mysql.com
O que você deve verificar antes da adoção?
Primeiro, verifique se as tabelas principais usam InnoDB e se os limites das transações correspondem às unidades de negócio. Alterações que devem ter sucesso ou falhar juntas, como a criação de um pedido, devem ser definidas como uma única transação, evitando transações desnecessariamente longas que aumentam a duração dos bloqueios. Segundo, liste as consultas de leitura e gravação mais frequentes e verifique se os índices necessários correspondem aos predicados reais e ao método de ordenação. dev.mysql.com dev.mysql.com
Terceiro, se você usar replicação, decida “quais leituras são permitidas nas réplicas”. Uma abordagem é distinguir solicitações que exigem atualidade, como verificar um status imediatamente após o pagamento, de consultas de listas e estatísticas que podem tolerar algum atraso. Quarto, se for necessária uma configuração de alta disponibilidade, teste cenários de falha não apenas para a eleição de membros do banco de dados, mas também para onde as conexões da aplicação realmente são movidas. dev.mysql.com dev.mysql.com
Quinto, suponha que os dados crescerão e verifique se o particionamento é realmente necessário e se você pode aceitar as restrições de chaves estrangeiras e chaves únicas. Se precisar de pesquisa de strings longas, pesquisa de texto completo e particionamento juntos, revise primeiro as limitações entre os recursos. Por fim, se junções complexas forem centrais, inspecione EXPLAIN em condições próximas aos dados de produção e avalie se você tem capacidade para gerenciar continuamente estatísticas e alterações de índices. dev.mysql.com dev.mysql.com dev.mysql.com
Conclusão: como avaliar os prós e contras do MySQL?
Os pontos fortes do MySQL incluem controle de transações e concorrência baseado em InnoDB, integração com uma ampla variedade de ambientes de desenvolvimento, distribuição de leitura por meio de replicação e recursos oficiais para construir configurações de alta disponibilidade. Eles podem fornecer uma base significativa para serviços web gerais e cargas de trabalho OLTP típicas. dev.mysql.com dev.mysql.com dev.mysql.com
Ao mesmo tempo, o possível atraso da replicação padrão, o projeto adicional para failover de conexão de alta disponibilidade, a validação de planos de execução para consultas complexas e as restrições relacionadas a índices, particionamento e pesquisa de texto completo devem ser considerados como custos reais. Em última análise, o MySQL não é uma escolha com qualidades universalmente positivas. É um banco de dados cuja adequação pode ser avaliada quando os requisitos de consistência dos dados, a proporção entre leituras e gravações, as restrições do esquema, o nível de resposta a falhas e a capacidade de ajuste e operação são especificados. dev.mysql.com dev.mysql.com dev.mysql.com