ALTER TABLE sur une grande table avec une colonne indexée

J'ai une grande table avec une colonne VARCHAR (20), et je dois la modifier pour devenir une colonne VARCHAR (50). En règle générale, l'exécution d'une ALTER TABLE (ajout d'un TINYINT) sur cette table particulière prend environ 90 à 120 minutes, donc je ne peux vraiment le faire que le samedi ou le dimanche soir pour éviter d'affecter les utilisateurs de la base de données. Si possible, je voudrais faire cette modification avant cela.

La colonne est également indexée, ce qui, je présume, ralentira ALTER TABLE, car elle doit reconstruire l'index après avoir modifié la longueur de la colonne.

L'application Web est installée dans un environnement de réplication MySQL (26 esclaves et un maître). Je me souviens d'avoir lu quelque part qu'une méthode consiste à exécuter d'abord la ALTER TABLE sur chaque esclave (minimiser l'impact sur les utilisateurs), puis à le faire sur le maître, mais cela n'essaiera-t-il pas alors de répliquer la commande ALTER TABLE sur les esclaves?

Ma question est donc: quelle est la meilleure façon pour moi de modifier ce tableau avec un minimum de perturbations pour mes utilisateurs?

Edit: la table est InnoDB.

Si vous êtes un peu aventureux, vous pouvez prendre les choses en main en effectuant la ALTER TABLE par étapes que vous pouvez voir. Supposons que la table que vous souhaitez modifier s'appelle WorkingTable. Vous pouvez effectuer les modifications par étapes comme ceci:

#
#  Script 1
#  Alter table structure of a single column of a large table
#
CREATE TABLE WorkingTableNew LIKE WorkingTable;
ALTER TABLE WorkingTableNew MODIFY BigColumn VARCHAR(50);
INSERT INTO WorkingTableNew SELECT * FROM WorkingTable;
ALTER TABLE WorkingTable RENAME WorkingTableOld;
ALTER TABLE WorkingTableNew RENAME WorkingTable;
DROP TABLE WorkingTableOld;

Vous pouvez effectuer cela sur tous les esclaves. Et le maître ??? Comment empêchez-vous cela de se répliquer sur les esclaves. Simple: N'envoyez pas le SQL dans les journaux binaires du maître. Fermez simplement la journalisation binaire dans la session avant de faire les choses ALTER TABLE:

#
#  Script 2
#  Alter table structure of a single column of a large table
#  while preventing it from replicating to slaves
#
SET SQL_LOG_BIN = 0;
CREATE TABLE WorkingTableNew LIKE WorkingTable;
ALTER TABLE WorkingTableNew MODIFY BigColumn VARCHAR(50);
INSERT INTO WorkingTableNew SELECT SQL_NO_CACHE * FROM WorkingTable;
ALTER TABLE WorkingTable RENAME WorkingTableOld;
ALTER TABLE WorkingTableNew RENAME WorkingTable;
DROP TABLE WorkingTableOld;

Mais attendez !!! Qu'en est-il des nouvelles données qui arrivent lors du traitement de ces commandes ??? Renommer la table au début de l'opération devrait faire l'affaire. Modifions un peu ce code pour éviter de saisir de nouvelles données à cet égard:

#
#  Script 3
#  Alter table structure of a single column of a large table
#  while preventing it from replicating to slaves
#  and preventing new data from entering into the old table
#
SET SQL_LOG_BIN = 0;
ALTER TABLE WorkingTable RENAME WorkingTableOld;
CREATE TABLE WorkingTableNew LIKE WorkingTableOld;
ALTER TABLE WorkingTableNew MODIFY BigColumn VARCHAR(50);
INSERT INTO WorkingTableNew SELECT SQL_NO_CACHE * FROM WorkingTableOld;
ALTER TABLE WorkingTableNew RENAME WorkingTable;
DROP TABLE WorkingTableOld;

• Le script 1 peut être exécuté sur n'importe quel esclave sur lequel les journaux binaires ne sont pas activés
• Le script 2 peut être exécuté sur n'importe quel esclave dont les journaux binaires sont activés
• Le script 3 peut être exécuté sur un maître ou n'importe où ailleurs

Essaie !!!

Ma conjecture de la documentation serait que simplement augmenter la contrainte de longueur sur un varcharne causerait pas le même problème que l'ajout d'une colonne:

Pour certaines opérations, une ALTER TABLE en place est possible qui ne nécessite pas de table temporaire:

Mais cela semble être contredit dans les commentaires sur cette question SO .

ÉDITER

Au moins sur 5.0, je pense pouvoir confirmer que l'augmentation de la longueur nécessite en effet une table temporaire (ou une autre opération tout aussi chère):

banc d'essai:

create table my_table (id int auto_increment primary key, varchar_val varchar(10));
insert into my_table (varchar_val)
select 'HELLO'
from (select 0 union all select 1 union all select 3 union all select 4 union all select 5 union all select 6 union all select 6 union all select 7 union all select 8 union all select 9) s1,
     (select 0 union all select 1 union all select 3 union all select 4 union all select 5 union all select 6 union all select 6 union all select 7 union all select 8 union all select 9) s2,
     (select 0 union all select 1 union all select 3 union all select 4 union all select 5 union all select 6 union all select 6 union all select 7 union all select 8 union all select 9) s3,
     (select 0 union all select 1 union all select 3 union all select 4 union all select 5 union all select 6 union all select 6 union all select 7 union all select 8 union all select 9) s4,
     (select 0 union all select 1 union all select 3 union all select 4 union all select 5 union all select 6 union all select 6 union all select 7 union all select 8 union all select 9) s5,
     (select 0 union all select 1 union all select 3 union all select 4 union all select 5 union all select 6 union all select 6 union all select 7 union all select 8 union all select 9) s6;

résultat:

alter table my_table modify varchar_val varchar(20);
Query OK, 1000000 rows affected (2.91 sec)

alter table my_table add int_val int;
Query OK, 1000000 rows affected (2.86 sec)

Je pensais, je mentionnerais que depuis le ENGINE=INNODB

Si vous avez des contraintes de clé étrangère, vous ne pouvez pas modifier et renommer sans vos contraintes pointant vers l'ancienne table (maintenant renommée). Vous devrez ensuite modifier ou supprimer les contraintes pour la durée.