Loops que precisam de transações normalmente pode ser codificados com a ajuda de LOCK TABLES, e você não precisa de cursores para atualizar regitros imeditamente.

Para evitar o uso do ROLLBACK, você pode usar as seguintes estratégias:

Isto é normalmente um método muito mais rápido que usar transações com possíveis ROLLBACKs, mas nem sempre. A única situação que esta solução não pode tratar é quando alguém mata a threads no meio de uma atualização. Neste caso, todas os locks serão liberados mas algumas das atualização podem não ter sido execuadas.

Você também pode usar funções para atualizar registros em uma única operação. Você pode conseguir uma aplicação muito eficiente usando as seguintes técnicas:

Por exemplo, quando fazemos atualizações em alguma informação de cliente, atualizamoa apenas os dados do clientes que alteraram e testamos apenas aqueles com dados alterados ou dados que dependem dos dados alterados, mudaram em comparação com o registro original. O teste dos dados alterados é feito com a cláusula WHERE na instrução UPDATE. Se o registro não foi atualizado, mandamos ao cliente uma mensagem: ''Some of the data you have changed has been changed by another user.'' Então mostramos o registro antigo versus o novo em uma janela, assim o utilizador pode decidir qual versão do registro de cliente de ser usado.

Isto nos dá algo similar a lock de colunas mas que, na verdade, é melhor porque apenas atualizamos algumas das colunas, usando valores relativos ao seu valor atual. Isto significa que instruções UPDATE comuns se parecem com estas:

UPDATE nometabela SET pay_back=pay_back+125;
UPDATE customer
SET
customer_date='current_date',
address='new address',
phone='new phone',
money_he_owes_us=money_he_owes_us-125
WHERE
customer_id=id AND address='old address' AND phone='old phone';

Como você pode ver, isto é muito eficiente e funciona mesmo se outro cliente alterar os valores nas colunas pay_back ou money_he_owes_us.

Em muitos casos, utilizadores querem fazer ROLLBACK e/ou LOCK TABLES com o propósito de gerenciarem identificadores únicos para algumas tabelas. Isto pode ser tratado muito mais eficientemente usando uma coluna AUTO_INCREMENT e também uma função SQL LAST_INSERT_ID() ou a função da API C mysql_insert_id(). See Secção 12.1.3.32, “mysql_insert_id()”.

Geralmente você pode codificar evitando lock de registro. Algumas situações realmente precisam disto, e tabelas InnoDB suportam lock de regitstro. Comoo MyISAM, você pode usar uma coluna de flag na tabela e fazer algo como a seguir:

UPDATE nome_tbl SET row_flag=1 WHERE id=ID;

O MySQL retorna 1 para o número de linhas afetadas se as linhas foram encontradas e row_flag já não era 1 na linha original.

Você pode pensar nisto como se o MySQL Server tivesse alterado a consulta anterior para:

UPDATE nome_tbl SET row_flag=1 WHERE id=ID AND row_flag <> 1;

Assumindo o projeto apropriado das relações, as restrições de chaves estrangeiras tornarão mais difícil para um programador introduzir uma inconsistência no banco de dados.

Usar atualizações e deleções em cascata pode simplificar o código do cliente.

Regras de chaves estrangeiras projetados apropriadamente ajudam ao documentar a relação entre as tabelas.

Erros, que são facéis de se ter ao projetar a relação das chaves, podem causar graves problemas¯por exemplo, regras circulares ou a combinação errada de uma deleção em cascata.

Verificação adicional no banco de dados afeta o desempenho, por esta razão algumas das principais aplicações comerciais codificam sua lógica no nível da aplicação.

Não é incomum para um DBA fazer uma topologia complexa de relações que torna muito difícl, e em alguns casos impossível, fazer backup ou restaurar tabelas individuais.

Pode se obter um deadlock ao fazer LOCK TABLE em multiplas tabelas e então na mesma conexão fizer um DROP TABLE em uma delas enquanto outra thread está tentando bloquear a tabela. Pode-se no entanto fazer um KILL em qualquer uma das threads envolvidas para resolver isto. Corrigido na versão 4.0.12

SELECT MAX(campo_chave) FROM t1,t2,t3... onde uma das três tabelas está vazia não retorna NULL, mas sim o valor máximo da coluna. Corrigido na versão 4.0.11.

DELETE FROM heap_table sem um WHERE não funcionam em tabelas HEAP com lock.

FLUSH TABLES WITH READ LOCK não bloqueia CREATE TABLE ou COMMIT, que pode criar um problema com a posição do log binário ao se fazer um backup completo de tabelas e do log binário.

ANALYZE TABLE em uma tabela BDB pode, em alguns, casos inutilizar a tabela até que se reinicie o servidor mysqld. Quando isto acontecer você irá ver o seguinte tipo de erro no arquivo de erros do MySQL.

001207 22:07:56 bdb: log_flush: LSN past current end-of-log

O MySQL aceita parenteses na parte FROM, mas os ignora sem aviso. A razão pela qual não são retornados erros é que muitos clientes que geram consultas automaticamente adicionam parentesis na parte FROM mesmo onde eles não são necessários.

Concatenar muitos RIGHT JOINS ou combinar joins LEFT e RIGHT na mesma consulta podem dar uma resposta incorreta ja que o MySQL só gera registros NULL para tabelas que precedem um join LEFT ou antes de um join RIGHT. Isto será corrigido na versão 5.0 junto com o suporte a parentesis na parte FROM.

Não execute ALTER TABLE em uma tabela BDB em que você estiver executando transações multi-instruções não completadas. (A transação provavelmente será ignorada).

ANALYZE TABLE, OPTIMIZE TABLE e REPAIR TABLE podem causar problemas em tabelas para as quais você estiver usando INSERT DELAYED.

Fazendo um LOCK TABLE .. e FLUSH TABLES .. não garante que não existem transações não terminadas em progresso na tabela.

Tabelas BDB são um pouco lentas para abrir. Se você tiver várias tabelas BDB em um banco de dados, gastará muito tempo para usar o cliente mysql no banco de dados se você não estiver usando a opção -A ou se você estiver usando rehash. Isto é percebido principalmente quando você tiver um cache de tabelas grandes.

A replicação utiliza o log a nivel de consulta: o master grava a consulta no log binário. Isto é um rápido, compacto e eficiente método de registro o que funciona perfeitamente na maioria dos casos. Embora nunca tenhamos ouvido sobre um caso ocorrido, há uma chance teórica que o dado no master e slave sejam diferente se uma consulta é feita de tal modo que a modificação do dado é não determinística, isto é, deixar ao desejo do otimizador de consultas (o que geralmente não é uma boa prática, mesmo fora da replicação!). Por exemplo:

Se e somente se todos estas consultas NÃO tiverem cláusulas ORDER BY garantindo uma ordem determinística.

Na verdade, por exemplo para INSERT ... SELECT sem ORDER BY, o SELECT pode retornar registros em uma ordem diferente (no qual resultará em um registro tendo diferentes posições, obtendo um número diferente na coluna auto_increment), dependendo da escolhe feita pelo otimizador no master e slave. Uma consulta será otimizada deiferentemente no master e slave apenas se:

Este problema também pode afetar a restauração de um banco de dados usando mysqlbinlog|mysql.

O modo mais fácil de evitar este problema em todos os casos é adicionar uma cláusula ORDER BY para tal consulta não determinística assegure que os registros são sempre armazenados/modificados na mesma ordem. Nas versões futuras do MySQL adicionaremos automaticamente uma cláusula ORDER BY quando necessário.

Ao usar funções RPAD, ou qualquer outra função string que termina adicionando espaços em branco a direita, em uma consulta que preisa usar tabelas temporárias para ser rsolvida, todas as strings resultantes serão cortadas a direita (como em RTRIM). Este é um exemplo de uma consulta:

SELECT RPAD(t1.field1, 50, ' ') AS f2, RPAD(t2.field2, 50, ' ') AS f1 FROM table1 as t1 LEFT JOIN table2 AS t2 ON t1.record=t2.joinID ORDER BY t2.record;

O resultado final deste erro é que o utilizador não conseguira espaços em branco do lado direito do campo resultante.

O comportamento anterior existe em todas as versões do MySQL.

A razão disto é devido ao fato de tabelas HEAP, que são usadas primeiro para tabelas temporárias, não são capazes de tratar colunas VARCHAR.

Este comportamento será corrigido em uma das distribuições da série 4.1.

Devido ao modo como os arquvos de definições de tabelas são armazenados não se pode usar 255 caracteres (CHAR(255)) em nomes de tabelas, nomes de colunas e enum. Isto está programado para ser corrigido na versão 5.1 quando temos novos arquivos de formatos de definição de tabelas.

Quando estiver usando SET CHARACTER SET, não é permitido usar caracteres especias no nome do banco de dados, tabelas ou campos.

Pode-se usar _ ou % com ESCAPE em LIKE ... ESCAPE.

se você tiver uma coluna DECIMAL com um número armazenado em diferentes formatos (+01.00, 1.00, 01.00), GROUP BY pode considerar cada valor como um valor diferente.

DELETE FROM merge_table usado sem WHERE irá apenas apagar o mapeamento para a tabela, não apagando tudo nas tabelas mapeadas.

Você não pode construir em outro diretório quando estiver utilizando MIT-pthreads. Como isto necessitaria de alterações na MIT-pthreads, nós não estamos aptos a corrigí-la.

BLOB valores não podem ser usados com confiança em GROUP BY, ORDER BY ou DISTINCT. Somente os primeiros bytes (padrão 1024) max_sort_length são usados quando estiver comparando BLOBs nestes casos. Isto pode ser alterado com a opção -0 max_sort_lenght para mysqld. Uma forma de contornar este problema para a maioria dos casos é usar a substring: SELECT DISTINCT LEFT(blob,2048) FROM nome_tabela.

Cálculos são feitos com BIGINT ou DOUBLE (normalmente, ambos tem o tamanho de 64 bits). Depende da precisão utilizada na função. A regra geral é que funções binárias são feitas com precisão BIGINT, IF e ELT() com precisão BIGINT ou DOUBLE e o resto com precisão DOUBLE. Devemos evitar o uso de valores sem sinal maiores que 63 bits (9223372036854775807) para qualquer outra coisa além de campos binários!

Todas os campos string, exceto campos do tipo BLOB e TEXTO tem, automaticamente, todos os espaços extras removidos quando recuperados. Para tipos CHAR, isto não tem problema, e pode ser considerado como um recurso de acordo com o ANSI SQL92. O problema é que no MySQL, campos VARCHAR são tratados desta mesma forma.

Você só pode ter até 255 colunas ENUM e SET em uma tabela.

Em MIN(), MAX() e outras funções de agrupamente, o MySQL atualmente compara as colunas ENUM e SET pelo valor de suas strings ao invés da posição relativa da string no conjunto.

mysqld_safe redireciona todas as mensagens de mysqld para o log mysqld. Um problema com isto é que se você executar o mysqladmin refresh para fechar e reabrir o log, a stdout e a stderr continuam redirecionadas para o log antigo. Se você utiliza --log extensivamente, deverá editar o mysqld_safe para logar em 'hostname'.err em vez de 'hostname'.log; assim você pode facilmente utilizar o espaço do log antigo apagando-o e executando mysqladmin refresh.

Em instruções UPDATE, colunas são atualizadas da esquerda para a direita. Se você referenciar a uma coluna atualizada, você irá obter o valor atualizado em vez do valor original, por exemplo:

mysql> UPDATE nome_tabela SET KEY=KEY+1,KEY=KEY+1;

Isto atualiza KEY com 2 no lugar de 1.

Você pode se referir a múltiplas tabelas em uma mesma consulta, mas você não pode se referir a qualquer tabelas temporárias dada mais de uma vez. Por exemplo, a seguinte instrução não funciona.

mysql> SELECT * FROM temporary_table, temporary_table AS t2;

RENAME não funciona com tabelas temporárias (TEMPORARY) ou tabelas usadas em uma tabelas MERGE.

O otimizador pode lidar com o DISTINCT de forma diferente se você estiver usando colunas 'escondidas' em uma join ou não. Em uma join, colunas escondidas são contadas como parte do resultado (mesmo se elas não são mostradas) enquanto que em queries normais colunas escondidas não participam na comparação DISTINCT. Nós provavelmente iremos alterar isto no futuro para nunca comparar as colunas escondidas quando executando DISTINCT.

um exemplo disto é:

SELECT DISTINCT mp3id FROM band_downloads
WHERE userid = 9 ORDER BY id DESC;

and

SELECT DISTINCT band_downloads.mp3id
FROM band_downloads,band_mp3
WHERE band_downloads.userid = 9
AND band_mp3.id = band_downloads.mp3id
ORDER BY band_downloads.id DESC;

No segundo caso, você pode obter duas linhas idênticas no MySQL 3.23.x na série do resultado (porque o campo escondido 'id' pode variar).

Perceba que isto somente acontece em consultas onde você não tem colunas ORDER BY no resultado, algo não permitido no SQL-92.

Como o MySQL permite trabalhar com tipos de tabelas que não suportam transações (e assim não pode fazer rollback em dados) algumas coisas funcionam um pouco diferentes de outros servidores SQL em MySQL (Isto serve para garantir que o MySQL nunca necessitará de um rollback para um comando SQL). Porém isto pode ser um pouco estranho em casos que os valores dos campos devem ser verificados na aplicação, mas isto ira fornacer um ótimo ganho de velocidade assim como permite ao MySQL fazer algumas otimizações que de outro modo seriam muito difíceis para serem feitas.

Se você informar um valor incorreto em uma coluna, o MySQL, em vez de fazer um rollback, aramzenará o melhor valor possível no campo.

Se você executar uma PROCEDURE em uma pesquisa que retorna uma série vazia, em alguns casos a instrução PROCEDURE não irá transformar as colunas.

Criação da tabela do tipo MERGE não verifiva se as tabelas envolvidas são de tipos compatíveis.

O MySQL ainda não pode lidar com valores NaN, -Inf e Inf em tipos double. Usá-los causará problemas na exportação e importação de dados. Uma solução intermediária é alterar NaN para NULL (se for possível) e -Inf e Inf para o valor double mínimo ou máximo respectivo possível.

Se você usar ALTER TABLE para primeiro adicionar um índice UNIQUE a uma tabela usada em uma tabela MERGE e então usar ALTER TABLE para adicionar um índice normal na tabela MERGE, a ordem das chaves será diferente para as tabelas se existir uma chave antiga não única na tabela. Isto é porque o ALTER TABLE coloca chaves UNIQUE antes de chaves normais para ser possível detectar chaves duplicadas o mais cedo o possível.

Você pode pendurar um processo se você fizer um DROP TABLE em uma tabela entre outras que esteja travada com LOCK TABLES.

No caso seguinte você pode obter um descarrego de memória para o arquivo core:

Antes da versão 3.23.2 do MySQL um UPDATE que atualizava uma chave com um WHERE na mesma chave podia falhar porque a chave era usada para procurar por registros e a mesma linha poderia ter encontrado vários itens:

UPDATE nome_tabela SET KEY=KEY+1 WHERE KEY > 100;

Um modo de contornar este erro é utilizar:

mysql> UPDATE nome_tabela SET KEY=KEY+1 WHERE KEY+0 > 100;

Isto funcionará porque MySQL não utilizará indices em expressões com a cláusula WHERE.

Antes da versão 3.23 do MySQL, todos os tipos numéricos tratados como campos de pontos fixos. Isto significa que você tem que especificar quantas casas decimais um campo de ponto flutuante deve ter. Todos os resultados eram retornados com o número correto de casas decimais.