Entendendo os problemas de bloqueio de linha de banco de dados e concorrência no MySQL

Linha da base de dados No MySQL, o bloqueio controla exatamente qual transação pode ler ou escrever quais linhas e quando, protegendo assim contra atualizações perdidas e leituras sujas. Vou mostrar, passo a passo, como os bloqueios, MVCC e como os níveis de isolamento interagem, onde surgem problemas de concorrência e como posso conceber consultas, índices e transações de forma a evitar bloqueios.

Pontos centrais

Para que possas perceber rapidamente qual é o foco deste artigo, vou resumir os princípios orientadores mais importantes e compará-los brevemente. Assim, terás uma estrutura concisa para os pontos mais aprofundados que se seguem Explicações.

• Bloqueios de remo limitar os conflitos a linhas individuais, em vez de tabelas inteiras.
• MVCC permite uma leitura rápida, sem bloqueios partilhados permanentes.
• Isolamento determina quais as anomalias que podem ocorrer.
• Tecla Gap/Next Bloquear lacunas no índice contra fantasmas.
• Melhores práticas reduzem significativamente os bloqueios e os impasses.

A seguir, traduzo estes pontos em medidas concretas que me permitem manter as instâncias produtivas do MySQL mais seguras e mais rápidas. Cada recomendação visa reduzir Bloqueio, dados consistentes e percursos de diagnóstico claros.

Por que é necessário o controlo da concorrência

Os acessos simultâneos entram em conflito assim que várias sessões tentam ler ou escrever nas mesmas linhas, razão pela qual optei por uma abordagem clara Limites de transação Oitavo. Sem regras, corre-se o risco de ocorrerem «Lost Updates», «Dirty Reads», «Non-Repeatable Reads» e «Phantoms», que acabam por provocar decisões erradas no código da aplicação. Evito isso garantindo a consistência de leitura e tornando visíveis os conflitos de gravação numa fase inicial, em vez de os substituir silenciosamente. Quanto mais utilizadores paralelos estiverem ativos, mais importantes se tornam os pequenos objetos de bloqueio e os Tempos de paragem. Quem ignorar isso, vai acabar por ter erros nos dados, com longas filas de espera e tempos de espera esgotados.

Noções básicas sobre o bloqueio de linhas no MySQL

O bloqueio de linhas aplica bloqueios a linhas individuais, permitindo que as outras linhas permaneçam livres e mais Paralelismo é criado. Um bloqueio exclusivo protege as operações de gravação até ao commit, enquanto os acessos de leitura utilizam bloqueios partilhados ou instantâneos MVCC, dependendo do nível de isolamento. Os bloqueios de intenção servem como sinais de nível superior, permitindo que o motor verifique mais rapidamente a compatibilidade dos bloqueios. Tenho sempre em conta que mesmo pequenas atualizações podem afetar muitas linhas se as condições WHERE forem imprecisas e não houver Índice conduz. A precisão no filtro evita intervalos de bloqueio amplos e preserva a concorrência.

A interação com os índices também é importante, pois o InnoDB bloqueia através de caminhos de índice; chaves ausentes ou inadequadas aumentam consideravelmente o número de linhas afetadas. Se uma instrução recorrer a uma varredura completa, o campo de bloqueio aumenta, o que prolonga os tempos de espera e favorece os deadlocks. Por isso, planeio desde o início as chaves adequadas para caminhos frequentes e mantenho as cláusulas WHERE o mais específicas possível. Assim, os meus bloqueios permanecem restritos e outras transações são processadas mais rapidamente. Acesso. Este é o ajuste mais simples para garantir um bloqueio suave.

Bloqueio pessimista vs. bloqueio otimista

O bloqueio pessimista parte do pressuposto de que existem conflitos e bloqueia logo no início, o que reforça a integridade, mas custa tempo, enquanto otimista Os sistemas em funcionamento só verificam no final se os dados foram alterados. Em configurações práticas do MySQL, combino as duas abordagens: para contas críticas, faço o registo com FOR UPDATE; para entidades que raramente entram em conflito, utilizo versões. Uma coluna de versão ou um carimbo de data/hora permite-me determinar, durante a atualização, se alguém foi mais rápido, sem bloquear a linha de forma permanente. Se ocorrer um conflito, repito a transação de forma seletiva ou executo uma lógica de negócio adaptada. Assim, distribuo a carga de forma mais eficiente, reduzo os tempos de espera e mantenho a Correção elevado.

Escolho a estratégia caso a caso: muitos acessos de leitura simultâneos beneficiam de abordagens otimistas, enquanto as transações financeiras ou de inventário altamente críticas dependem de bloqueios exclusivos curtos, mas claros. O objetivo é sempre bloquear apenas o necessário e detetar conflitos numa fase precoce. Com esta abordagem, evito longas cadeias de sessões em espera. Isso aumenta a taxa de processamento e Fiabilidade na vida quotidiana.

Compreender os níveis de isolamento e o MVCC

O nível de isolamento determina quantas anomalias permito e o grau de bloqueio do MySQL, razão pela qual seleciono o nível de forma deliberada, de acordo com o caso de uso. READ COMMITTED impede acessos de leitura sujos, REPEATABLE READ mantém os valores de uma transação consistentes e SERIALIZABLE estabelece a sequência mais rigorosa. O InnoDB utiliza MVCC, para que os leitores possam, na maioria das vezes, passar sem bloqueios partilhados e, mesmo assim, ver instantâneos consistentes. Quem trabalha com isto deve compreender quando os bloqueios Gap e Next-Key entram em ação adicionalmente para evitar fantasmas. Para uma análise mais aprofundada, vale a pena consultar Detalhes sobre os níveis de isolamento, para que possas avaliar corretamente os efeitos em cada nível.

A tabela seguinte classifica os níveis mais comuns em relação a anomalias típicas e ao impacto nos bloqueios, para que eu possa fazer a escolha adequada e evitar Bloqueio evitar.

Nível de isolamento	Anomalias permitidas	Comportamento de bloqueio (simplificado)	Utilização típica
LER SEM COMPROMISSO	Dirty Reads, Non-Repeatable, Phantoms	Poucos bloqueios, elevada Riscos	Raramente faz sentido
READ COMMITTED	Não repetíveis, fantasmas	Os leitores utilizam o MVCC, os gravadores X-Locks	Relatórios, APIs com muitas leituras
REPEATABLE READ	Phantoms com desconto na Next-Key	Elevada consistência de leitura, direcionada Gap-Bloquear	Padrão no InnoDB
SERIALIZÁVEL	Sem anomalias	Bloqueios mais amplos, menores Paralelismo	Processos altamente críticos

Normalmente, começo com REPEATABLE READ e faço correções pontuais quando as consultas ficam demasiado bloqueadas devido a bloqueios Next-Key. Por outro lado, só utilizo SERIALIZABLE nos casos em que é tecnicamente inevitável, pois, caso contrário, os tempos de espera acumulam-se. Com uma escolha clara para cada carga de trabalho, mantenho os dados consistentes e, ao mesmo tempo, protejo a Desempenho. Esta abordagem poupa tempo de assistência técnica, uma vez que os picos inesperados de bloqueios ocorrem com menos frequência. Assim, o sistema mantém-se previsível, mesmo com o aumento do número de utilizadores.

A concorrência no MySQL na prática

Uma boa concorrência começa com consultas bem formuladas, que selecionam apenas as linhas realmente necessárias, para que o InnoDB possa Row-pode causar bloqueios. Tenho o cuidado de garantir que as condições de filtragem sejam executáveis por meio de índices, ou seja, que sejam processadas através de índices e não exijam chamadas de funções nas colunas. Mantenho as atualizações focadas: cláusula WHERE clara, índice adequado, sem junções desnecessárias na mesma instrução. Em casos de reservas, utilizo FOR UPDATE com moderação e apenas para os registos de dados efetivamente afetados. Além disso, evito interações prolongadas do utilizador entre BEGIN e COMMIT, pois cada segundo aumenta o tempo de espera de outras sessões.

Ao inserir dados em espaços de índice densos, tenho em conta que podem ocorrer bloqueios Next-Key, o que faz com que mais transações fiquem em espera. Distribuo os pontos de pico dispersando os espaços de chaves ou descarregando o caminho de gravação para uma pequena fila independente. Desta forma, reduzo as colisões na tabela mais ativa. Este ajuste fino tem um efeito mais forte do que aumentar os tempos de espera, porque menos Conflitos nem sequer ocorram. É precisamente por isso que vale a pena medir os acessos aos dados antes da entrada em funcionamento.

Problemas típicos de concorrência: bloqueios, impasses, escopo dos bloqueios

O bloqueio ocorre quando uma transação fica à espera de uma linha já bloqueada, razão pela qual procuro manter as transações curtas e a linha em questão Quantidade limitar. Os deadlocks ocorrem quando duas transações bloqueiam-se mutuamente, o que o MySQL deteta e, consequentemente, interrompe uma delas. Respondo a isso com tentativas de repetição direcionadas e uma ordem de acesso consistente em todos os caminhos de código. A escalada de bloqueios é menos frequente no InnoDB, mas os limites internos restringem a complexidade administrativa; varreduras de grande porte aproximam o mecanismo desses limites. Quem observar deadlocks recorrentes deve verificar o Detecção e resolução de impasses analisar sistematicamente e eliminar as fontes de conflito, em vez de se limitar a aumentar os tempos de espera.

Pela minha experiência, há três padrões que causam tempos de espera particularmente longos: filtros não indexados em tabelas muito consultadas, FOR UPDATE sem uma cláusula WHERE exata e lógica de negócio extensa entre as etapas de leitura e gravação. Elimino-os medindo cada caminho individualmente, reduzindo o tempo de bloqueio e ajustando as instruções SQL aos caminhos de índice. Pequenas alterações no filtro ou na ordem das atualizações resolvem frequentemente problemas complexos. Essas correções são mais económicas do que mais Hardware, porque têm um efeito duradouro. Só depois disso vale a pena pensar em expansão vertical ou horizontal.

Boas práticas para evitar bloqueios e impasses

Concluo as transações rapidamente e não deixo formulários de entrada abertos enquanto os bloqueios estão ativos, porque cada segundo é uma perda desnecessária Filas de espera provocadas. Abordo sempre as tabelas e as linhas na mesma ordem, para evitar dependências cíclicas. Para operações de leitura pura, o modo READ COMMITTED é frequentemente suficiente, enquanto que, em atualizações críticas, utilizo o modo REPEATABLE READ ou, temporariamente, o modo FOR UPDATE. O design de índices continua a ser obrigatório: sem uma chave adequada, uma instrução bloqueia rapidamente demasiadas linhas. O tratamento de erros também faz parte: deteto erros de deadlock, registo todos os detalhes e tento uma solução curta e limpa Repetir.

A monitorização completa o pacote: observo os tempos de espera, as contagens de deadlocks e os planos de consulta, e otimizo primeiro os picos mais evidentes. Pequenas melhorias nos hotpaths compensam imenso, porque afetam todas as consultas. Assim, consigo menos bloqueios, maior rendimento e tempos de resposta fiáveis. Esta abordagem é muito mais eficaz no dia-a-dia do que grandes remodelações. Rotinas bem definidas são mais eficazes do que soluções genéricas Acções quase sempre.

Dicas específicas do MySQL para aumentar a concorrência

Utilizo o autocommit de forma deliberada: as instruções individuais beneficiam com isso, enquanto as alterações interligadas são agrupadas numa instrução curta e clara Transação . Utilizo a instrução SELECT … FOR UPDATE com moderação e apenas para registos que realmente precise de reservar. Desvio relatórios longos para réplicas ou sistemas analíticos, para que as cargas de trabalho OLTP não fiquem em espera. Além disso, verifico regularmente quais as instruções que mantêm um número invulgarmente elevado de bloqueios e porquê. Quem quiser aprofundar o assunto deve consultar o Mecanismo de armazenamento InnoDB e avaliar cuidadosamente os esquemas de índices no contexto do seu próprio esquema, antes de a próxima versão entrar em produção.

Minimizo os pontos de congestionamento escolhendo as chaves primárias de forma a que a carga de gravação não se concentre permanentemente no final de um índice que cresce de forma monótona. Também divido as operações em lote em pequenas partes, para não gerar bloqueios exclusivos prolongados. Com estas ferramentas, os bloqueios duram menos tempo e a contenção diminui de forma mensurável. Isso reduz a taxa de erros e a aplicação responde com maior fluidez. Assim, aproveito reservas sem ter de criar imediatamente novas Servidor acumular.

Monitorização e análise: o que eu avalio

Vou começar com métricas relativas aos tempos de espera de bloqueio, ao número de deadlocks, às transações demoradas e às instruções mais executadas por tempo de execução, para poder identificar os maiores Alavanca identifico. O Performance Schema, o comando SHOW ENGINE INNODB STATUS e os registos de consultas lentas fornecem-me pistas concretas. Em seguida, analiso os planos das consultas mais problemáticas e verifico se faltam índices ou se os filtros não são pesquisáveis. Assim que elimino os gargalos, observo o efeito ao longo de várias fases de carga. Este ciclo de medição, alteração e verificação permite que o qualidade a concorrência aumenta sensivelmente.

Para obter conclusões fiáveis, preciso de dados de teste realistas e padrões de acesso reais, e não apenas testes sintéticos de um único ciclo. Perfis de carga com sessões simultâneas mostram como os bloqueios funcionam na prática. Esses testes revelam pontos críticos ocultos que, no dia a dia, só seriam detectados mais tarde. Quem testa as versões desta forma evita surpresas na operação ao vivo. Isso poupa custos, tempo e nervos a longo prazo Ver.

Ambiente de alojamento e desempenho da base de dados

Uma boa concorrência depende de hardware rápido, pois qualquer atraso na E/S prolonga o Duração da atração. Presto atenção a SSDs rápidos, memória RAM suficiente para os buffers e caminhos curtos entre a aplicação e a base de dados. As reservas de CPU ajudam a executar consultas paralelas sem congestionamentos. Reduzo sistematicamente as latências de rede, para que as idas e voltas não aumentem o tempo de bloqueio efetivo. Quem mantiver estas condições em mente obterá um sistema com boa capacidade de resposta Serviços e menos abortos.

Também são importantes as estratégias de escalabilidade adequadas: réplicas de leitura para relatórios, sharding para conjuntos de dados muito grandes e sistemas separados para cargas de trabalho de análise. Só escolho qual a opção mais vantajosa após uma avaliação e evito decisões precipitadas. A arquitetura e a disciplina SQL complementam-se; sem consultas adequadas, o hardware compensa apenas a curto prazo. Com uma combinação adequada, reduzo significativamente os conflitos de bloqueio. O resultado é uma experiência de utilizador fiável, sem Tempos de espera.

Tipos de bloqueio no InnoDB em detalhe

Para tomar decisões precisas sobre os caminhos de consulta, conheço bem os principais tipos de bloqueio: os bloqueios de registo bloqueiam entradas individuais do índice, os bloqueios de intervalo bloqueiam o espaço entre duas entradas do índice e os bloqueios de chave seguinte são uma combinação de ambos. Estes últimos evitam fantasmas nas varreduras de intervalo. Os bloqueios de intenção de inserção (Insert-Intention-Locks) sinalizam intenções de inserção e permitem inserções paralelas em diferentes lacunas, sem se interferirem desnecessariamente. Em pesquisas únicas através de um índice único, o InnoDB reduz o bloqueio a um Record-Lock, o que minimiza os bloqueios. Assim que um predicado de intervalo entra em jogo (BETWEEN, >, LIKE com prefixo), é frequentemente aplicado um Next-Key-Lock e, consequentemente, uma área de bloqueio mais ampla.

Por isso, planeio as consultas de forma a que, sempre que possível, utilizem índices únicos ou altamente seletivos. Não é apenas a condição WHERE que é determinante: também a ordem das cláusulas ORDER BY, LIMIT e JOIN influencia o caminho do índice selecionado – e, consequentemente, a extensão do bloqueio. Uma reescrita direcionada, que utilize um ORDER BY com o índice adequado, pode evitar bloqueios Next-Key e reduzir significativamente os tempos de espera.

Utilizar as «Locking-Reads» de forma seletiva

As leituras com bloqueio são úteis quando preciso reservar linhas ou coordenar atualizações concorrentes. No MySQL, utilizo:

• SELECT … FOR UPDATE: bloqueio exclusivo nas linhas lidas, adequado para reservas antes de uma atualização.
• SELECT … FOR SHARE (ou LOCK IN SHARE MODE nas versões mais antigas): bloqueio partilhado para garantir leituras consistentes com proteção contra gravação.
• NOWAIT e SKIP LOCKED: evitam longos tempos de espera – NOWAIT interrompe imediatamente, SKIP LOCKED ignora as linhas bloqueadas.

Um padrão comum para filas de tarefas:

START TRANSACTION;
SELECT id, payload
FROM jobs
WHERE status = 'ready'
ORDER BY priority, id
LIMIT 50
FOR UPDATE SKIP LOCKED;
-- marcar como 'processing' e confirmar
UPDATE jobs SET status = 'processing' WHERE id IN (...);
COMMIT;

É assim que processei as tarefas em paralelo, sem que se bloqueassem mutuamente. O importante é: cláusulas WHERE precisas, um índice adequado em (status, priority, id) e transações curtas.

Compreender os bloqueios de metadados (MDL)

Para além dos bloqueios de linha, existem bloqueios de metadados que coordenam as operações DDL e DML. Cada consulta em execução mantém um bloqueio de leitura MDL nas tabelas em questão; as operações DDL requerem bloqueios MDL exclusivos. Um ALTER TABLE iniciado de forma imprudente pode, por isso, ter de esperar até que transações ou relatórios demorados terminem – inversamente, um DDL bloqueia, por sua vez, novos acessos DML. Por isso, planeio alterações de esquema fora dos horários de pico, reduzo a duração das transações e verifico, antes das implementações, se as sessões mantêm as tabelas abertas durante vários minutos. As variantes de DDL online atenuam muitos problemas, mas não substituem a disciplina em relação aos tempos de transação. Na monitorização, observo especificamente as esperas MDL, porque estas sinalizam congestionamentos evitáveis.

Chaves estrangeiras, cascatas e obrigatoriedade de indexação

As chaves estrangeiras aumentam a qualidade dos dados, mas ampliam a pegada de bloqueio. O InnoDB verifica a consistência através de índices – se estes estiverem em falta nas colunas de chave estrangeira, corre-se o risco de varreduras extensas e bloqueios prolongados. Por isso, asseguro a existência de índices em todas as colunas de referência. As atualizações/eliminações em cascata podem bloquear várias tabelas numa transação, favorecendo assim os deadlocks. Defino uma ordem de acesso fixa em todas as tabelas afetadas e mantenho as alterações pequenas. Nos casos em que as cascatas são raras do ponto de vista técnico, procuro alternativas: passos explícitos e curtos com condições WHERE claras, para manter a duração do bloqueio previsível.

Autoincremento, pontos de acesso e inserções em massa

As chaves primárias com crescimento monótono criam um ponto de congestionamento no final do índice agrupado. Muitas inserções paralelas convergem nesse ponto, o que aumenta os tempos de espera. Eu distribuo as chaves (por exemplo, através de chaves de partição ou ID de entidade prefixada) ou utilizo tamanhos de lote curtos que são confirmados de forma limpa. Controlo o comportamento de autoincremento através do modo de bloqueio: para OLTP, prefiro configurações que permitam inserções paralelas e bloqueiem apenas por breves períodos. Em lotes grandes, verifico se um caminho semelhante a COPY ou pequenos subconjuntos repetíveis são mais rápidos. O importante é: criar índices apenas após grandes processos de carregamento ou aliviar os índices secundários durante o mesmo, para reduzir os pontos de congestionamento de inserção.

Replicação e leituras consistentes

Ao ler réplicas, tenho em conta os atrasos: caso contrário, um relatório pode apresentar dados desatualizados. Para obter instantâneos consistentes, inicio transações deliberadamente com WITH CONSISTENT SNAPSHOT e defino READ ONLY quando se trata apenas de leitura. Assim, mantenho uma visão estável ao longo de várias instruções – sem bloqueios desnecessários. Ao mesmo tempo, certifico-me de que a aplicação tenha percursos tolerantes em caso de atrasos na replicação ou, se necessário, recorra ao servidor primário quando a atualidade absoluta for crucial. Isso reduz surpresas e explica aparentes „anomalias“ que, na verdade, são apenas latências de replicação.

Configuração e estratégias de nova tentativa

Ajusto os tempos de espera de bloqueio e a deteção de forma adequada: um valor moderado para innodb_lock_wait_timeout evita que as sessões fiquem bloqueadas durante minutos. Deteto deadlocks de forma proativa e faço uma distinção clara: o erro 1213 (deadlock) é recuperado rapidamente com backoff e jitter; o erro 1205 (lock wait timeout) é interpretado como um sinal para otimizar o caminho da consulta. O innodb_deadlock_detect ajuda em muitas transações curtas; em casos de paralelismo extremamente elevado, a sua relação custo-benefício pode virar-se contra nós – nesse caso, a resolução dos pontos críticos é quase sempre a melhor resposta do que a simples alteração de parâmetros.

As tentativas repetidas só são seguras se as operações forem idempotentes. Eu desenho os percursos de atualização de forma a que uma nova tentativa atinja o mesmo estado final (por exemplo, com colunas de versão, conjuntos determinísticos em vez de incrementos ou eventos de negócio claros). Desta forma, evito registos duplicados e mantenho o código robusto contra conflitos inevitáveis.

Exemplos: lotes sem bloqueios gerais

Divido as grandes alterações em pequenas partes indexadas, com base na chave primária:

-- Exemplo: Eliminação em lotes
SET @last_id = 0;
WHILE 1 DO
  DELETE FROM events
  WHERE id > @last_id
  ORDER BY id
  LIMIT 1000;
  SET @rows = ROW_COUNT();
  IF @rows = 0 THEN LEAVE; END IF;
  SET @last_id = (SELECT MAX(id) FROM events WHERE id <= @last_id + 1000);
END WHILE;

Este padrão mantém as transações curtas, reduz os tempos de bloqueio e permite que outras cargas de trabalho tenham espaço para funcionar. Faço o mesmo com atualizações em massa: primeiro seleciono os IDs de destino num conjunto temporário (ou através de uma janela LIMIT), depois gravo de forma direcionada e confirmo rapidamente.

Guia rápido de diagnóstico

Quando os tempos de espera aumentam, sigo uma ordem fixa:

1. Identificar o sintoma: quais as tabelas, quais as instruções, a que horas?
2. Tornar visíveis as cadeias de espera: no Performance Schema, identificar os data_locks/data_lock_waits e os PIDs bloqueantes; além disso, verificar o estado atual do InnoDB.
3. Verificar o plano de consulta: a consulta utiliza o índice esperado? Os predicados são agrupáveis?
4. Reduzir o âmbito do bloqueio: especificar a condição WHERE, adicionar índices, evitar varreduras de intervalo e restringir as leituras com bloqueio.
5. Reduzir a duração da transação: remover interações e chamadas externas da transação, reduzir os conjuntos de resultados.
6. Repetir e medir: após a alteração, observar novamente os picos de consumo e compará-los.

Este procedimento evita que se avance às cegas. Em vez de aumentar os prazos, elimino as causas – de forma mais sustentável e, na maioria das vezes, mais rápida.

Evitar armadilhas operacionais

Há três aspetos a que presto especial atenção durante a operação: em primeiro lugar, evito desativar acidentalmente o autocommit a nível global – isso prolonga os bloqueios sem que se perceba. Em segundo lugar, evito que os pools de ligações transmitam transações que já mantêm bloqueios abertos. Em terceiro lugar, utilizo os pontos de salvamento de forma específica para reversões parciais, mas não espero que encurtem os tempos de retenção dos bloqueios: o bloqueio permanece até ao commit ou rollback. Uma disciplina clara na camada de aplicação traduz-se aqui diretamente em tempos de espera mais curtos.

Em resumo: principais lições aprendidas

O bloqueio de linhas garante a consistência dos dados, mas apenas em conjunto com MVCC, com um nível de isolamento adequado e um design de índices bem estruturado, é aí que ele revela o seu potencial. Procuro manter as transações curtas, filtrar de forma seletiva e utilizo FOR UPDATE apenas nos casos em que a reserva é tecnicamente necessária. Reduzo os conflitos através de sequências de acesso consistentes e novas tentativas claras em caso de deadlocks. Escolho os níveis de isolamento por caso de uso e observo o impacto dos bloqueios Gap e Next-Key. Quem procede com rigor e faz ajustes regulares alcança um alto Concorrência sem surpresas.

No final, o que conta são três coisas: objetos de bloqueio pequenos, tempos de retenção curtos e percursos de consulta rastreáveis. Com estes princípios, as cargas de trabalho do MySQL funcionam de forma fiável, mesmo quando há muitos utilizadores ativos em simultâneo. Apostamos em testes repetíveis, métricas significativas e otimizações específicas em vez de grandes remodelações. Assim, os dados permanecem corretos, os tempos de resposta baixos e os deadlocks raros. É exatamente isso que todas as equipas esperam de um sistema ágil Base de dados.