Na versão 5.6 do MySQL, agora é possível realizar vários tipos de operações DDL em tabelas InnoDB à quente, com atraso mínimo em operações DML sobre tabelas, sem que seja necessário reconstruir a tabela inteira. (O InnoDB é o mecanismo de armazenamento padrão do MySQL desde a versão 5.5.)
A melhoria reduz o tempo de resposta e aumenta a disponibilidade em ambientes de produção muito ocupados. Nesses ambientes, pode não ser viável deixar uma tabela indisponível, mesmo por minutos, quando for necessário mudanças estruturais em tabelas.
Versões anteriores
Até a versão 5.1, era muito custoso apagar índices secundários, ou adicionar/descartar índices em base de dados existentes. Operações DDL, como CREATE INDEX e ALTER TABLE, trabalhavam em uma nova tabela vazia e copiavam as linhas da tabela antiga para a nova, uma a uma; os índices eram atualizados gradualmente, e após a cópia de todas as linhas da tabela original, esta tabela era descartada. A nova tabela era então rebatizada com o nome da original. Na versão 5.5, para reduzir os atrasos causado pela criação de nova tabela, os comandos CREATE INDEX e DROP INDEX tiveram seus comportamentos otimizados. Porém, havia ainda a necessidade de interromper o uso da tabela pelo o tempo necessário à manutenção.
MySQL 5.6 e alterações à quente
No MySQL 5.6, os comandos CREATE INDEX e DROP INDEX ganharam mais melhorias. Agora é possível realizar comandos DML enquanto a tabela está sendo alterada. Há aprimoramentos em várias outras operações DDL, que antes exigiam uma cópia da tabela, bloqueio de operações DML, ou ambos.
A criação e remoção de índices secundários em tabelas tipo InnoDB evitam a cópia da tabela desde a versão 5.1 do MySQL, por meio do plugin InnoDB. Mas com a nova abordagem, a tabela continua disponível para operações de leitura e escrita, enquanto o índice está sendo criado ou removido. Os comandos CREATE TABLE ou DROP TABLE só concluem depois que terminam todas as operações modificando a tabela, para que o estado inicial do índice possa refletir os conteúdos mais atuais. Anteriormente, modificar uma tabela, enquanto um índice estava sendo criado ou removido resultava em deadlock, o que cancelava os comandos de inserção, atualização ou exclusão na tabela.
Agora é possível alterar o valor de autoincremento para uma coluna, com a base de dados no ar. Como exemplo, em um sistema distribuído, usando replicação ou sharding, às vezes é necessário reiniciar o contador de autoincremento de para um valor específico. A próxima linha inserida na tabela fará uso do valor especificado para a coluna de autoincremento sem que seja necessário bloquear o uso da tabela . É possível também fazer adição ou remoção de restrições em chaves estrangeiras e renomear colunas com o banco em operação. Além disso, algumas outras operações ALTER TABLE são executadas de forma mais rápida devido à otimização do procedimento de cópia de tabela.
Desempenho e disponibilidade
Ao evitar a cópia de tabelas em operações DDL, são melhorados vários aspectos da operação do MySQL, incluindo desempenho, concorrência, disponibilidade e escalabilidade. Segundo o manual do MySQL 5.6:
Ao evitar escritas e leituras de disco (I/O) e ciclos de CPU para reconstruir uma tabela, é possível diminuir a carga total sobre o servidor de banco de dados. Como menos dados são carregados para o buffer, evita-se a tarefa de limpar os dados mais acessados do cache de memória. [...] Por haver um período mais curto enquanto as consultas e operações DML são realizadas, até que a fila de espera da operação DDL conclua, há menos bloqueios e esperas para todos os outros recursos do MySQL. Reduzir a carga adicional aumenta a escalabilidade, mesmo para operações que não envolvam a tabela que está sendo alterada.
No tópico referente ao InnoDb do Manual do MySQL 5.6 estão detalhadas todas as informações necessárias para tirar proveito deste novo recurso.