Код помилки 1117 Забагато стовпців; Ліміт стовпців MySQL на столі

У мене є таблиця з 1699 стовпцями, і коли я намагаюся вставити більше стовпців, я отримую,

Код помилки: 1117. Забагато стовпців

У цій таблиці я лише 1000 рядків. Для мене найголовніше - кількість стовпців. Чи є якісь обмеження на столі? Я хочу створити 2000 стовпців. Це можливо?

Навіщо вам потрібно створити таблицю з навіть 20 стовпцями, не кажучи вже про 2000 ???

Надані, денормалізовані дані можуть запобігти необхідності JOIN для отримання багатьох стовпців даних. Однак якщо у вас більше 10 стовпців, вам слід зупинитися і подумати про те, що буде під кришкою під час пошуку даних.

Якщо таблиця стовпців 2000 зазнає SELECT * FROM ... WHERE, ви будете генерувати великі тимчасові таблиці під час обробки, вибирати непотрібні стовпці та створювати безліч сценаріїв, коли пакети зв'язку ( max_allowed_packet ) будуть висунуті на межі кожного запиту.

У попередні дні як розробник я працював у компанії ще в 1995 році, де DB2 був основною RDBMS. Компанія мала єдину таблицю, яка складала 270 стовпців, десятки індексів і мала проблеми з результатами пошуку даних. Вони зв’язалися з IBM і мали консультантів, які розглядають архітектуру своєї системи, включаючи цю єдину монолітну таблицю. Компанії сказали: "Якщо ви не нормалізуєте цю таблицю протягом наступних 2 років, DB2 не зможе виконати запити, що виконують Stage2 Processing (будь-які запити, що потребують сортування за неіндексованими стовпцями). Про це було сказано багатомільйонній компанії, щоб нормалізувати таблицю з 270 стовпчиків. Наскільки більше, так 2000 таблиця стовпців.

З точки зору mysql, вам доведеться компенсувати такий поганий дизайн, встановивши параметри, порівнянні з DB2 Stage2 Processing. У цьому випадку такі варіанти були б

• max_allowed_packet
• tmp_table_size
• max_tmp_tables
• max_heap_table_size
• max_length_for_sort_data
• max_sort_length
• sort_buffer_size
• myisam_max_sort_file_size
• myisam_sort_buffer_size

Налаштування цих параметрів компенсує наявність десятків, не кажучи вже про сотні, стовпців, добре працює, якщо у вас є ТБ оперативної пам’яті.

Ця проблема множиться геометрично, якщо ви використовуєте InnoDB, оскільки вам доведеться мати справу з MVCC (Multiversion Concurrency Control), намагаючись захистити тонни стовпців з кожним SELECT, UPDATE та DELETE шляхом ізоляції транзакцій.

ВИСНОВОК

Немає замінника чи пов'язки, яка може компенсувати поганий дизайн. Будь ласка, заради вашого розуму в майбутньому нормалізуйте цю таблицю сьогодні !!!

У мене виникають труднощі уявити що-небудь, де модель даних може законно містити 2000 стовпців у нормально нормалізованій таблиці.

Я здогадуюсь, що ви, ймовірно, робите якусь денормалізовану схему "заповнення пробілів", де ви фактично зберігаєте всі різні види даних в одній таблиці, а замість того, щоб розбивати дані на окремі таблиці та встановлювати відносини , у вас є різні поля, які записують, який "тип" даних зберігається в заданому рядку, і 90% ваших полів - NULL. Навіть тоді, хотіти, щоб дістатися до 2000 колонок ... виходить.

Рішення вашої проблеми - переосмислити вашу модель даних. Якщо ви зберігаєте велику купу ключових / значущих даних, пов’язаних із заданим записом, чому б не моделювати це саме так? Щось на зразок:

CREATE TABLE master (
    id INT PRIMARY KEY AUTO_INCREMENT,
    <fields that really do relate to the
    master records on a 1-to-1 basis>
);

CREATE TABLE sensor_readings (
    id INT PRIMARY KEY AUTO_INCREMENT,
    master_id INT NOT NULL,   -- The id of the record in the
                              -- master table this field belongs to
    sensor_id INT NOT NULL,
    value VARCHAR(255)
);

CREATE TABLE sensors (
    id INT PRIMARY KEY AUTO_INCREMENT,
    <fields relating to sensors>
);

Потім отримати всі записи датчика, пов'язані з заданою "основною" записом, ви можете просто SELECT sensor_id,value FROM sensor_readings WHERE master_id=<some master ID>. Якщо вам потрібно отримати дані для запису в masterтаблиці разом з усіма датчиковими даними для цього запису, ви можете використовувати з'єднання:

SELECT master.*,sensor_readings.sensor_id,sensor_readings.value
FROM master INNER JOIN sensor_readings on master.id=sensor_readings.master_id
WHERE master.id=<some ID>

А далі приєднуйтесь, якщо вам потрібні деталі того, що таке кожен датчик.

Це система вимірювання з 2000 датчиками

Ігноруйте всі коментарі, що кричать про нормалізацію - те, про що ви просите, може бути розумним дизайном баз даних (в ідеальному світі) і ідеально добре нормалізованим, це просто дуже незвично, і як зазначалося в інших місцях, RDBMS зазвичай просто не розроблені для цього багатьох стовпців .

Хоча ви не досягаєте жорсткого обмеження MySQL , один з інших факторів, згаданих у посиланні, ймовірно, заважає вам піднятися вище

Як говорять інші, ви можете подолати це обмеження, маючи дочірню таблицю id, sensor_id, sensor_value, або, простіше кажучи, ви можете створити другу таблицю, яка містить лише стовпці, які не вмістяться в першому (і використовувати той самий ПК)

Ліміти підрахунку стовпців MySQL 5.0 (наголос додано):

Існує жорсткий ліміт - 4096 стовпців на таблицю , але ефективний максимум може бути меншим для даної таблиці. Точна межа залежить від кількох взаємодіючих факторів.

• Кожна таблиця (незалежно від двигуна зберігання) має максимальний розмір рядків 65,535 байт.Двигуни зберігання можуть обмежувати додаткові обмеження, зменшуючи ефективний максимальний розмір рядка.

  Максимальний розмір рядка обмежує кількість (і, можливо, розмір) стовпців, оскільки загальна довжина всіх стовпців не може перевищувати цей розмір.

...

Окремі двигуни зберігання можуть встановити додаткові обмеження, які обмежують кількість стовпців таблиці. Приклади:

• InnoDB дозволяє розміщувати до 1000 стовпців.

Спочатку ще трохи полум’яного, а потім справжнє рішення ...

Я здебільшого погоджуюся з уже викинутим на вас полум’ям.

Я не згоден з нормалізацією ключових значень. Результати запитів жахливі; продуктивність ще гірша.

Один "простий" спосіб уникнути негайної проблеми (обмеження кількості стовпців) - "вертикально розділити" дані. Майте, скажімо, 5 таблиць із 400 стовпчиками у кожній. Усі вони матимуть однаковий первинний ключ, за винятком одного, він може бути AUTO_INCREMENT.

Можливо, краще було б визначитися з десятками полів, які є найважливішими, і помістити їх у «головну» таблицю. Потім згрупуйте датчики якимось логічним способом і поставте їх у кілька паралельних таблиць. При правильному групуванні вам, можливо, не доведеться постійно приєднуватися до всіх таблиць.

Ви індексуєте якесь із значень? Вам потрібно пошукати їх? Можливо, ви шукаєте на дату?

Якщо вам потрібно проіндексувати багато стовпців - punt.

Якщо вам потрібно проіндексувати декілька - покладіть їх у головну таблицю.

Ось справжнє рішення (якщо воно застосовується) ...

Якщо вам не потрібен великий масив датчиків, індексований, то не робіть стовпчиків! Так, ви мене почули. Натомість збирайте їх у JSON, стискайте JSON, зберігайте у полі BLOB. Ви заощадите тонну місця; у вас буде лише одна таблиця, без проблем з обмеженням стовпців; т. т. Ваша програма не скасуватиме, а потім використовувати JSON як структуру. Вгадай що? Ви можете мати структуру - ви можете згрупувати датчики в масиви, багаторівневі речі тощо, так, як хотів би ваш додаток. Ще одна «особливість» - це відкритість. Якщо ви додасте більше датчиків, вам не потрібно ЗНАЧІТЬ таблицю. JSON, якщо таким чином гнучким.

(Стиснення необов’язкове; якщо ваш набір даних величезний, це допоможе простору на диску, отже, і загальній продуктивності.)

Я розглядаю це як можливий сценарій у світі великих даних, де ви, можливо, не виконуєте традиційні запити select *. Ми маємо справу з цим у світі прогнозування моделювання на рівні клієнтів, де ми моделюємо клієнта у тисячах вимірів (усі вони мають значення 0 або 1). Цей спосіб зберігання полегшує діяльність з побудови моделі за течією тощо тощо, коли у вас є фактори ризику в одному рядку та прапор результату в тому ж рядку. Це можна нормалізувати з точки зору зберігання з батьківською дочірньою структурою, але передбачувальна модель вниз за течією потребує перетворення її назад в плоску схему. Ми використовуємо червону зміну, яка виконує стовпчастий накопичувач, тому ваші 1000+ стовпців при завантаженні даних фактично зберігаються у стовпчастому форматі ...

Є час і місце для цього дизайну. Зовсім. Нормалізація - це не рішення кожної проблеми.