MySQL alter table de modifier la colonne d'échec lignes avec des valeurs null

J'ai une table avec environ 10K lignes, que je suis en train de modifier de sorte que le champ fielddelimiter n'est jamais null. Je suis tenter de faire une instruction alter, s'attend à aucun de valeurs null changé la valeur par défaut, mais j'obtiens une erreur de l'instruction sql.

alter table merchant_ftp_account modify column `fielddelimiter` char(1) NOT NULL DEFAULT 't';

17:08:48  [ALTER - 0 row(s), 0.000 secs]  [Error Code: 1265, SQL State: 01000]  Data truncated for column 'fielddelimiter' at row 3987
... 1 statement(s) executed, 0 row(s) affected, exec/fetch time: 0.000/0.000 sec  [0 successful, 0 warnings, 1 errors]

Si je comprends bien, cela signifie que les données dépasse la taille du champ à cette ligne, mais (a) les données dans le champ (null) à la ligne, et (b) je suis en mesure de mettre à jour cette ligne directement avec la valeur "t", et je ne suis pas une erreur de troncation. Si je mettre à jour cette ligne avec une valeur non null et essayer de ré-exécuter l'instruction alter, il ne parvient pas à la ligne suivante, où fielddelimiter est null. [ETA: je reçois que MySQL pourrait mise à jour dans n'importe quelle direction, mais j'arrive à suivre son progrès que j'ai du changer les lignes.]

Il y a un avertissement dans le MySQL docs:

Warning This conversion may result in alteration of data. For example, if you shorten a
string column, values may be truncated. To prevent the operation from succeeding if
conversions to the new data type would result in loss of data, enable strict SQL mode
before using ALTER TABLE (see Section 5.1.6, Server SQL Modes”).

Mais les valeurs qu'il est soi-disant en tronquant sont les valeurs null. Quelqu'un peut-il m'expliquer ce qui se passe ici? Et comment le résoudre?

[ETA: L' fielddelimiter définition du champ est de type char(1) (nulls, pas de valeur par défaut), donc il ne devrait pas avoir de valeurs > 1 char, et une sélection de confirme qu'il n'a pas. Les valeurs distinctes dans le domaine sont NULL, " (chaîne vide), 'p', 't', et 'y'.]

  • Je tiens à ajouter que j'ai aussi essayé de faire une mise à jour de toutes les lignes où ce champ est null, et la requête prend jamais (pour l'instant j'ai arrêté de courir après 10 et 15 minutes). Ma mise à jour est: update merchant_ftp_account set fielddelimiter = 't' where fielddelimiter IS NULL;
  • quel est le type de ton champ? si votre type est quelque chose qui peut contenir une valeur plus grande, je suppose, mysql est de penser qu'il y a plus de valeurs présents dans la colonne.
  • si votre mise à jour est lente, un index sur la colonne, puis essayez la mise à jour stmt.
  • Les indices d'améliorer les temps de recherche. Vous ne pouvez pas magiquement faire écrit plus rapidement. Et, en fait, si quelque chose que votre suggestion rend les choses plus lent que l'index doit être reconstruit. Les index sont un outil qui doit être utilisé avec précision, pas aveuglément et carrément jeté à n'importe quel problème que vous rencontrez dans le vague espoir qu'ils vont comme par magie "accélérer ma requête"
  • la construction des indices sur 10k lignes ne devrait pas prendre une éternité! depuis la mise à jour stmt est à l'aide d'une clause where..il y a une recherche impliquée n'est-ce pas?
  • En effet. Les mises à jour (pouvez) utiliser les recherches de trop. Un indice pourrait aider ici. Mais je pense que c'est une autre question ensemble. Peut-être que nous devrions nous concentrer sur l'original.
  • Je devrais probablement avoir mentionné que le type de champ avant de tenter de modifier la table est de type char(1). Les seuls changements que j'ai fais ne permettent pas de valeur null, et de fournir une valeur par défaut.
  • qu'advient-il si vous remplacez les valeurs NULL avec votre valeur par défaut par une instruction de mise à jour et ensuite faire de l'instruction ALTER TABLE?

InformationsquelleAutor barclay | 2011-10-19