Есть ли снижение производительности, если в таблице слишком много столбцов?
Есть ли затраты на производительность при наличии большого количества столбцов в таблице, помимо увеличения общего объема данных? Если да, поможет ли разделение таблицы на несколько более мелких?
6 ответов
Если вам действительно нужны все эти столбцы (то есть, это не просто признак того, что у вас плохо спроектированная таблица), то, конечно, сохраняйте их.
Это не проблема производительности, если вы
- используете соответствующие индексы для столбцов, которые вам нужны для выбора строк
- не извлекаете столбцы, которые вам не нужны в операциях SELECT
Если у вас 30 или даже 200 столбцов, это не проблема для базы данных. Вы просто заставляете ее работать немного сложнее, если хотите получить все эти столбцы сразу.
Но наличие большого количества столбцов - это плохой запах кода; я не могу придумать ни одной законной причины, по которой хорошо спроектированная таблица имела бы такое количество столбцов, и, возможно, вместо этого вам нужны отношения "один-ко-многим" с какой-то другой, гораздо более простой таблицей.
Помимо производительности, нормализация базы данных необходима для баз данных со слишком большим количеством таблиц и связей. Нормализация дает вам легкий доступ к вашим моделям и гибкие отношения для выполнения различных запросов sql.
Как показано здесь , существует восемь форм нормализации. Но для многих систем достаточно применения первой, второй и третьей нормальных форм.
Таким образом, вместо выбора связанных столбцов и написания длинных SQL-запросов лучше использовать хорошие нормализованные таблицы базы данных.
30 колонок обычно не считаются чрезмерным количеством.
Три тысячи столбцов, с другой стороны... Как бы вы реализовали очень широкую "таблицу"?
С технической точки зрения 30 столбцов - это абсолютно нормально. Однако таблицы с большим количеством столбцов часто являются признаком того, что ваша база данных не нормализована должным образом, то есть она может содержать избыточные и / или несогласованные данные.
Все должно быть хорошо, если только у вас нет select * from yourHugeTable повсюду. Всегда выбирайте только те столбцы, которые вам нужны.
Я собираюсь взвесить это, даже если вы уже выбрали ответ. Да, слишком широкие таблицы могут вызвать проблемы с производительностью (а также проблемы с данными), и их следует разделять на таблицы со связями один-один. Это связано с тем, как база данных хранит данные (ну, по крайней мере, в SQL Server не уверены в mySQl, но стоит почитать документацию о том, как база данных хранит данные и обращается к ним).
Тридцать столбцов могут быть слишком широкими, а может и нет, это зависит от их ширины. Если вы сложите общее количество байтов, которые будут занимать ваши 30 столбцов, будет ли оно шире, чем максимальное количество байтов, которое может быть сохранено в записи?
Некоторые из столбцов вам понадобятся реже, чем другие (другими словами, существует ли естественное разделение между требуемой и часто используемой информацией и другими вещами, которые могут появляться только в одном месте, а не где-либо еще), а затем рассмотрите возможность разделения таблицы.
Если некоторые из ваших столбцов представляют собой такие вещи, как phone1, phone2, phone3 - тогда не имеет значения, сколько столбцов у вас есть, вместо этого вам нужна связанная таблица с отношением «один ко многим».
В общем, 30 столбцов - это не слишком много и, вероятно, подойдет.