Переполнение строки varchar2 в mysql

у меня есть сервер mysql 5.1.50. Недавно я создал файл дампа для некоторых старых таблиц с данными, преобразованными из старых версий mysql. во время импорта я получил сообщения «Данные усечены для столбца». короткий поиск показал, что есть строки со значениями varchar, которые превышают определенное значение varchar таблицы.

  1. как это возможно? пытался воссоздать его безуспешно, кто-нибудь сталкивался с таким состоянием?
  2. как я могу найти проблемные строки без полного сканирования всей таблицы?
  3. самое главное, могут ли это быть фиксы (опять же, при простом решении полный дроп-создать не поможет)

из db (данные скрыты, но настоящие выборки):

desc xxx

+----------------+------------------+------+-----+---------+----------------+
| Field          | Type             | Null | Key | Default | Extra          |
+----------------+------------------+------+-----+---------+----------------+
| id             | int(10) unsigned | NO   | PRI | NULL    | auto_increment |
| date           | date             | NO   | MUL | NULL    |                |
| int1           | int(10) unsigned | NO   |     | NULL    |                |
| v1             | varchar(200)     | NO   |     | NULL    |                |
| v2             | varchar(200)     | NO   |     | NULL    |                |
| i2             | int(10) unsigned | NO   |     | NULL    |                |
| i3             | int(10) unsigned | NO   |     | NULL    |                |
| f1             | float            | NO   |     | NULL    |                |
| f2             | float            | NO   |     | NULL    |                |
+----------------+------------------+------+-----+---------+----------------+

select count(id) from xxx where length(v1)>200 group by length(v1);

+-----------+------------------+
| count(id) | length(v1)       |
+-----------+------------------+
|         7 |              201 |
|         1 |              202 |
|         1 |              203 |
|         5 |              204 |
|         1 |              205 |
|         1 |              206 |
|         5 |              207 |
|         9 |              208 |
|         4 |              209 |
|         1 |              210 |
|        67 |              212 |
|        13 |              214 |
|         1 |              215 |
|         1 |              216 |
|         2 |              220 |
|         2 |              221 |
|         2 |              230 |
|         2 |              235 |
|         1 |              274 |
|         1 |              290 |
|         1 |              320 |
+-----------+------------------+

mysql varchar
person user1092332    schedule 11.12.2011    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Определите, что ваши поля varchar должны быть больше 200 символов.

Значения в столбцах VARCHAR представляют собой строки переменной длины. Длина может быть указана как значение от 0 до 255 до MySQL 5.0.3 и от 0 до 65 535 в 5.0.3 и более поздних версиях. Эффективная максимальная длина VARCHAR в MySQL 5.0.3 и более поздних версиях зависит от максимального размера строки (65 535 байт, который используется всеми столбцами) и используемого набора символов.

Подробнее читайте в руководстве по MySQL.

Приведенное выше утверждение говорит о том, что вы можете определить столбцы varchar с длиной более 255, как долго сумма размеров всех столбцов varchar из этой таблицы не превышает 65 535. Чтобы быть более конкретным, вы можете изменить столбцы таблицы:

ALTER TABLE xxx CHANGE v1 v1 VARCHAR(500);
person cristian    schedule 11.12.2011

arrow_upward
0
arrow_downward

  1. Кажется, что по крайней мере некоторые строковые значения многобайтовые (length() возвращает размер в байтах, char_length() - размер в символах
  2. SELECT * FROM your_table WHERE LENGTH(v1) != CHAR_LENGTH(v1)
  3. Обычно скрипт импорта/экспорта должен заботиться о таких вещах (при условии, что ваш целевой сервер поддерживает многобайтовые символы). Какой инструмент вы используете для экспорта/импорта? Насколько я знаю, у mysqldump такой проблемы нет.
person a1ex07    schedule 11.12.2011