Início / dba / Perguntas / 334444
Accepted
catsarethebest
Asked: 2023-12-31 16:49:00 +0800 CST

Por que criar um índice no MySQL (InnoDB) e depois travar deliberadamente não resulta em uma reversão?

  • 772

Eu criei esta tabela USERS com `10 milhões de registros

mysql> desc users;
+--------+--------------+------+-----+---------+-------+
| Field  | Type         | Null | Key | Default | Extra |
+--------+--------------+------+-----+---------+-------+
| id     | int          | NO   |     | NULL    |       |
| name   | varchar(255) | NO   |     | NULL    |       |
| email  | varchar(255) | NO   |     | NULL    |       |
| gender | varchar(10)  | NO   |     | NULL    |       |
+--------+--------------+------+-----+---------+-------+

Agora tenho 2 sessões de terminal, session_1 e session_2. Na session_1, executei este comando

mysql> alter table users add  primary key(id);

Enquanto este comando alter na sessão_1 ainda estava em andamento, na sessão 2, eu mato o cliente mysql usando

kill -9 <mysql_session_id>

Quando reinicio o cliente mysql, emito desc USERSmais uma vez, não vejo nenhuma chave primária na coluna id, mas depois de um minuto ou mais, vejo que a chave primária está lá na idcoluna.

mysql> desc users;
+--------+--------------+------+-----+---------+-------+
| Field  | Type         | Null | Key | Default | Extra |
+--------+--------------+------+-----+---------+-------+
| id     | int          | NO   | PRI | NULL    |       |
| name   | varchar(255) | NO   |     | NULL    |       |
| email  | varchar(255) | NO   |     | NULL    |       |
| gender | varchar(10)  | NO   |     | NULL    |       |
+--------+--------------+------+-----+---------+-------+
4 rows in set (0.01 sec)

Eu também tentei comset autocommit=0

mysql

1 respostas

  1. Best Answer

    Antes da versão 8.0, as instruções DDL (como ALTER) eram executadas sem ACID transacional. (Isto é, autocommite BEGIN..COMMITnão foram homenageados.)

    CREATE TABLE tmp LIKE real;
ALTER tmp as per your statement
INSERT INTO tmp SELECT * FROM real;
RENAME TABLE real TO old, tmp TO real;
DROP TABLE old;

    Se o cliente fosse embora ou o sistema travasse antes do RENAME, o processo era encerrado. (Muitas vezes o "tmp" era deixado no disco.)

    O RENAME é rápido e essencialmente atômico, então, assim que passar por isso, a ação estará concluída.

    (Existem alguns bloqueios que não listei.)

    O MySQL 8.0 faz o mesmo, mas com BEGINe COMMITem torno dessas instruções, além de ter um novo código para poder fazer isso ROLLBACK.

    Voltando à sua pergunta... Efetivamente, o código antigo teve quase o efeito do novo código, pois a morte do cliente provavelmente aconteceu antes do RENAME, portanto, parecia que foi revertido.

    Observe também que a INSERTinstrução leva mais tempo - porque ela deve copiar todos os dados, possivelmente em uma ordem diferente. (Os dados são armazenados em uma árvore B+ baseada na chave primária.) Ele também reconstruirá todos os secundários.INDEXes

    Qual versão você está executando? Talvez você esteja executando a versão 8.0 e seu ALTER tenha realmente terminado, mas levou algum tempo para que os bloqueios fossem colocados no lugar. Isso pode explicar o atraso na exibição do DESC. (Não acho que nenhum desenvolvedor Oracle esteja acompanhando este fórum, então você pode não obter uma resposta definitiva aqui. Você pode postar um bug em bugs.mysql.com na esperança de obter uma resposta.)

    • 3

relate perguntas