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

Ответ 1

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

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

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

Ответ 7

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

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

Ответ 8

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

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

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

• name - CHAR (70)
• пол - TINYINT (1)
• age - TINYINT (2)
• bio - ТЕКСТ

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

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

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

Ответ 9

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