Есть ли снижение производительности, если в таблице слишком много столбцов?

Если вам действительно нужны все эти столбцы (то есть это не просто признак того, что у вас плохо спроектированная таблица), непременно сохраните их.

Это не проблема производительности, если вы

• используйте соответствующие индексы для столбцов, которые необходимо использовать для выбора строк
• не извлекайте столбцы, которые вам не нужны в операциях SELECT

Если у вас 30 или даже 200 столбцов, это не проблема для базы данных. Вы просто усложняете ему работу, если хотите получить сразу все эти столбцы.

Но наличие большого количества столбцов - плохой запах кода; Я не могу придумать какой-либо законной причины, по которой хорошо спроектированная таблица будет иметь такое количество столбцов, и вместо этого вам может потребоваться связь «один-много» с какой-либо другой, гораздо более простой таблицей.

Я не согласен со всеми этими сообщениями, утверждающими, что 30 столбцов пахнут плохим кодом. Если вы никогда не работали с системой, в которой была сущность с 30+ допустимыми атрибутами, то у вас, вероятно, не так много опыта.

Ответ, предоставленный HLGEM, на самом деле лучший из всех возможных. Мне особенно нравится его вопрос «есть ли естественное разделение ... часто используемые и не часто используемые?» - очень хорошие вопросы, которые стоит задать себе, и вы можете разделить таблицу естественным образом (если все сложится). из рук).

Мой комментарий был бы следующим: если ваша производительность в настоящее время приемлема, не пытайтесь изобретать новое решение, если оно вам не нужно.

Я собираюсь взвесить это, даже если вы уже выбрали ответ. Да, слишком широкие таблицы могут вызвать проблемы с производительностью (а также проблемы с данными), и их следует разделять на таблицы с отношениями один-один. Это связано с тем, как база данных хранит данные (ну, по крайней мере, в SQL Server не уверены в MySQL, но стоит почитать документацию о том, как база данных хранит данные и получает доступ к ним).

Тридцать столбцов могут быть слишком широкими, а может и нет, это зависит от их ширины. Если вы сложите общее количество байтов, которое займут ваши 30 столбцов, будет ли оно больше максимального количества байтов, которое может быть сохранено в записи?

Некоторые из столбцов вам понадобятся реже, чем другие (другими словами, существует ли естественное разделение между требуемой и часто используемой информацией и другими данными, которые могут появляться только в одном месте, а не где-либо еще), тогда рассмотрите возможность разделения таблицы.

Если некоторые из ваших столбцов представляют собой такие вещи, как phone1, phone2, phone3 - тогда не имеет значения, сколько столбцов у вас есть, вместо этого вам нужна связанная таблица с отношением «один ко многим».

В общем, хотя 30 столбцов не являются необычно большими и, вероятно, будут в порядке.

С технической точки зрения 30 столбцов - это абсолютно нормально. Однако таблицы с большим количеством столбцов часто являются признаком того, что ваша база данных не нормализована должным образом, то есть она может содержать избыточные и / или несогласованные данные.

Должно быть хорошо, если только у вас не select * from yourHugeTable повсюду. Всегда выбирайте только те столбцы, которые вам нужны.

30 мне кажется не слишком много. В дополнение к необходимым индексам и правильным запросам SELECT для широких таблиц применимы два основных совета:

1. Определите столбец как можно меньше.
2. Избегайте использования динамических столбцов таких как VARCHAR или TEXT, насколько это возможно, когда у вас есть большое количество столбцов в таблице. Попробуйте использовать столбцы фиксированной длины, например CHAR. Это сделано для того, чтобы сэкономить дисковое пространство для производительности.

Например, для столбцов «имя», «пол», «возраст», «биография» в таблице «человек» до 100 или даже более столбцов, чтобы максимизировать производительность, их лучше всего определить как:

1. имя - CHAR (70)
2. пол - TINYINT (1)
3. возраст - TINYINT (2)
4. био - ТЕКСТ

Идея состоит в том, чтобы определять столбцы как можно меньше и по возможности фиксированной длины. Динамические столбцы должны находиться в конце структуры таблицы, поэтому перед ними ВСЕ столбцы фиксированной длины.

Само собой разумеется, что это приведет к огромному объему дискового пространства, потраченному впустую из-за большого количества строк, но если вам нужна производительность, я предполагаю, что это будет цена.

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

30 столбцов обычно не считаются чрезмерным числом.

С другой стороны, три тысячи столбцов ... Как бы вы реализовали очень широкий стол?

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

Как показано здесь, существует восемь форм нормализации. Но для многих систем достаточно применения первой, второй и третьей нормальных форм.

Таким образом, вместо выбора связанных столбцов и написания длинных SQL-запросов лучше использовать хорошие нормализованные таблицы базы данных.

С точки зрения использования это уместно в некоторых ситуациях, например, когда таблицы обслуживают несколько приложений, которые используют одни столбцы, но не другие, и где для отчетности требуется единый пул данных в реальном времени для всех, без передачи данных. Если таблица из 200 столбцов обеспечивает такую ​​аналитическую мощь и гибкость, то я бы сказал «открывайте длинную позицию». Конечно, в большинстве ситуаций нормализация обеспечивает эффективность и является наилучшей практикой, но делайте то, что вам нужно.