Decisão: qual nível de isolamento?

O nível de isolamento de transação determina o equilíbrio entre concorrência e consistência. Isolamento maior significa menos anomalias, porém mais bloqueios/conflitos e novas tentativas. Esta árvore ajuda a escolher entre Read Committed, Repeatable Read/Snapshot e Serializable com base em quais anomalias de leitura (dirty, non-repeatable, phantom) você pode tolerar.

Você pode tolerar dirty reads?

Comece pela anomalia mais básica: uma transação deve poder ler dados que ainda não foram confirmados (e que podem sofrer rollback)? Quase nenhuma aplicação séria quer isso; na maioria dos engines modernos, o padrão já impede dirty reads. Só é relaxado para contagens aproximadas/analíticas e velocidade máxima.

• Não, devo ler apenas dados confirmados
• Sim, uma leitura aproximada basta (raro)

Você precisa ver o mesmo resultado ao reler dentro da mesma transação?

Descartados os dirty reads, a próxima pergunta: se você ler a mesma linha duas vezes dentro de uma transação, é um problema ver um valor diferente porque alguém fez commit no meio (non-repeatable read), ou que surjam novas linhas (phantom)? Lógicas que exigem consistência de relatório/cálculo geralmente precisam de um snapshot consistente.

• Não, tudo bem cada instrução ver os dados confirmados mais recentes
• Sim, é necessário um snapshot consistente para a transação inteira

As transações concorrentes precisam ser logicamente totalmente ordenadas?

Você quer leituras consistentes; isso basta, ou as transações concorrentes precisam produzir um resultado como se tivessem sido executadas uma a uma, em sequência (serializable)? Se você puder tolerar anomalias sutis como write skew (ex.: duas transações lendo linhas diferentes e gravando de forma a invalidar uma à outra), Snapshot basta; caso contrário, é necessária a serialização completa.

• Não, um snapshot consistente basta
• Sim, nenhuma anomalia de concorrência é aceitável

Recomendação: Read Uncommitted (apenas casos especiais)

O isolamento mais baixo; permite dirty reads. Lê quase sem esperar por locks, mas você pode ver dados que podem sofrer rollback. Não recomendado para aplicações de uso geral.

Recomendação: Read Committed (OLTP padrão)

Cada instrução vê os dados mais recentes confirmados naquele momento; dirty reads são impedidos. É o padrão na maioria dos engines e oferece o melhor equilíbrio entre concorrência e consistência para cargas OLTP típicas.

Recomendação: Repeatable Read / Snapshot (leituras consistentes)

A transação trabalha sobre um snapshot consistente fixado no seu início (ou na sua primeira leitura); as leituras não mudam durante a transação. Com MVCC, leitores não bloqueiam escritores e escritores não bloqueiam leitores.

Recomendação: Serializable (isolamento completo)

O isolamento mais alto: transações concorrentes produzem um resultado como se tivessem sido executadas serialmente (uma a uma, em sequência). Impede todas as anomalias de leitura e o write skew; o preço é mais conflitos e a necessidade de novas tentativas.