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

Question

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

Answer 5

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

Answer 6

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

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

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

1. name - CHAR (70)
2. пола - TINYINT (1)
3. age - TINYINT (2)
4. bio - TEXT

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

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

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

Answer 7

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

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

Answer 8

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

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

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

Answer 9

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