MySQL: ограничение размера столбца

Question

В настоящее время я работаю над ОС Windows, и я установил сервер сообщества MySQL 5.6.30, и все в порядке. У меня есть скрипт, который инициализирует БД и снова, все работает нормально.

Теперь я пытаюсь запустить этот скрипт на среде Linux - та же версия MySQL - и я получаю следующее сообщение об ошибке:

ERROR 1074 (42000) at line 3: Column length too big for column 'txt' (max = 21845); use BLOB or TEXT instead

Script -

DROP TABLE IF EXISTS text; 
CREATE TABLE `texts` (
    `id` BINARY(16) NOT NULL DEFAULT '\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0', 
    `txt` VARCHAR(50000) DEFAULT NULL, 
    PRIMARY KEY (`id`) 
) ENGINE=INNODB DEFAULT CHARSET=utf8; 

Очевидно, что есть некоторые Конфигурация сервера MySQL на моей ОС Windows, которую мне нужно реплицировать на Linux; может ли кто-нибудь поделиться идеями?

Update 1

на RDS AWS схемы также работает и им вполне уверен, что его просто сервис поверх Linux так, очевидно, его просто вопрос конфигурации.

любое тело знает, как добраться до varchar 50k с помощью UTF8?. я не хочу использовать TEXT или MEDIUMTEXT или любой другой, просто старый VARCHAR (размер)

Update 2

я ценю различные решения, которые были предложены, но им не ищут нового им решения только глядя для ответа, как и почему varchar (50k) работает под окнами, а под linux - нет. Btw, im, используя набор charcter UTF8 и сортировку utf8_general_ci.

Ответ

ответить на мой собственный вопрос, это был вопрос с sql_mode был установлен в STRICT_TRANS_TABLES и должны были быть удалены.

Answer 1

пожалуйста, просто используйте TEXT объявить Txt столбец

DROP TABLE IF EXISTS text; 
CREATE TABLE `texts` (
    `id` BINARY(16) NOT NULL DEFAULT '\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0', 
    `txt` TEXT DEFAULT NULL, 
    PRIMARY KEY (`id`) 
) ENGINE=INNODB DEFAULT CHARSET=utf8; 

Answer 2

Согласно документации:

Although InnoDB supports row sizes larger than 65,535 bytes internally, MySQL itself imposes a row-size limit of 65,535 for the combined size of all columns:

mysql> CREATE TABLE t (a VARCHAR(8000), b VARCHAR(10000), 
    -> c VARCHAR(10000), d VARCHAR(10000), e VARCHAR(10000), 
    -> f VARCHAR(10000), g VARCHAR(10000)) ENGINE=InnoDB; 

ERROR 1118 (42000): Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. You have to change some columns to TEXT or BLOBs

(К сожалению, этот пример не предоставляет набор символов, поэтому мы не знаем, как на самом деле большие столбцы.)

Кодирование utf8 использует 1, 2 или 3 байта на символ. Таким образом, максимальное количество символов, которые могут безопасно вписываться в страницу из 65,535 байт (максимум MySQL), составляет 21 845 символов (21,845 * 3 = 65,535).

Несмотря на то, что версии похожи, Windows выглядит консервативно в своем распределении по пространству и гарантирует, что вы можете хранить любые символы в поле. Linux, похоже, имеет отношение laissez-faire. Вы можете сохранить некоторые строки с более чем 21 845 символами, в зависимости от персонажей.

Я понятия не имею, почему эта разница существует в той же версии. Оба метода являются «правильными» в некотором смысле. Есть достаточно простые обходы:

• Использование TEXT.
• Переключитесь на сортировку с более короткими символами (которые, предположительно, вы хотите сохранить).
• Уменьшить размер поля.

Answer 3

Если вы абсолютно должны использовать varchar - это плохое решение этой проблемы! - то вот что вы можете попробовать:

CREATE TABLE `texts` (
    `id` BINARY(16) NOT NULL DEFAULT '\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0', 
    `txt` VARCHAR(20000) DEFAULT NULL, 
    PRIMARY KEY (`id`) 
) ENGINE=INNODB DEFAULT CHARSET=utf8; 

CREATE TABLE `texts2` (
    `id` BINARY(16) NOT NULL DEFAULT '\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0', 
    `txt` VARCHAR(20000) DEFAULT NULL, 
    PRIMARY KEY (`id`) 
) ENGINE=INNODB DEFAULT CHARSET=utf8; 

CREATE TABLE `texts3` (
    `id` BINARY(16) NOT NULL DEFAULT '\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0', 
    `txt` VARCHAR(10000) DEFAULT NULL, 
    PRIMARY KEY (`id`) 
) ENGINE=INNODB DEFAULT CHARSET=utf8; 

Всего 50000 символов. Теперь вашему клиентскому приложению придется управлять разбиением текста на отдельные куски и создавать записи в каждой таблице. Аналогично, чтение текста обратно потребует от вас сделать 3 оператора select, но у вас будет 50000 символов.

Это совсем не рекомендуется делать с любой реализацией базы данных.

Я работал в нескольких средах, где большой текст хранился в столбцах в базе данных, и он всегда вызывал больше проблем, чем он решался.

Они должны быть действительно буферизированы для файлов на диске и ссылки на полный путь к файлу, хранящемуся в базе данных.

Затем запустите этот механизм индексации над этим корпусом документов.

вы получите большую масштабируемость от этого и упростите управление.

Answer 4

utf8 требует до 3 байтов на символ. utf8mb4: 4; latin1: 1; ascii: 1; и т. д. VARCHAR(N) реализован как длина 1 или 2 байта перед байтами для текста. Этому разрешено удерживать N символов (а не байтов). Итак, если вы говорите, что хотите utf8, то 3 * N должно быть меньше 65535, максимальное значение для 2-байтовой длины.

Радуйтесь вы не работаете в какой-то старой версии, где VARCHAR имел предел 255.

Если txt кроме ASCII или английского языка не нужно символов, а затем использовать CHARACTER SET latin1.

В InnoDB, когда есть «длинные» поля (большие varchars, тексты, капли и т. Д.), Некоторые или все столбцы хранятся в отдельном блоке. Ограничение составляет около 8000 байт для того, что хранится вместе в записи.

Если вам действительно нужно 50K utf8, то MEDIUMTEXT - это то, что вам нужно. Он использует длину 3 байта и может содержать до 16 Мбайт (5 М символов, возможно, больше, поскольку utf8 - кодирование с переменной длиной).

Большинство приложений могут (должны?) Использовать либо ascii (1 байт за символ), либо utf8mb4 (1-4 байта на символ). Последний позволяет использовать все языки, включая Emoji и 4-байтовые китайские символы, которые utf8 не может справиться.

Что касается того, почему Windows и Linux работают по-другому здесь, я не знаю. Вы используете ту же версию? Предложите вам подать отчет об ошибке с http://bugs.mysql.com. (И дайте ссылку на него из этого Вопроса.)