Важно не количество столбцов в таблице, а "ширина" таблицы.
Например, если все 50 из этих столбцов являются бит столбцами, то вы смотрите на 7 байтов в строке, что составляет крошечный .
С другой стороны, если все 50 столбцов являются VARCHAR(4000) столбцами, то вы смотрите на потенциальный максимальный размер строки около 200 МБ на строку (да, SQL Server позволит вам это сделать), что, очевидно, может вызвать проблемы (на самом деле это, вероятно, не будет, но я хочу сказать, что важна ширина данных, а не количество столбцов.
Только верный способ узнать, возникнут ли у вас проблемы, - это попробовать и увидеть, но как правило очень общее хорошая идея попытаться сохранить размер строки ниже 4 КБ (1 страница), однако это очень общее правило:
- Обычно вы, вероятно, хотите, чтобы размер строки был на намного * на 1022 * меньше этого значения, чтобы вы могли разместить много строк на странице
- Однако, если в вашей таблице есть пара больших полей объекта (например,
VARCHAR или VARCHAR(MAX)), размеры строк, вероятно, будут довольно регулярно превышать 4 КБ, это нормально.
Это сложный вопрос - как я сказал, единственный верный способ узнать это попробовать и посмотреть, работает ли он.
Обратите внимание, что за исключением крупных объектов (таких как VARCHAR), SQL Server не позволит вам создать строку размером более 1 страницы.
Почему "широкая" таблица может вызвать проблемы?
Потому что это увеличивает объем данных, которые необходимо прочитать.
В качестве очень простого / надуманного примера предположим, что у вас есть таблица, упорядоченная по идентификатору (то есть имеет кластеризованный индекс по идентификатору), и вы хотите получить записи для идентификаторов от 100 до 110 включительно. Если размер строки небольшой (скажем, 200 байт), то размер всех этих записей вместе составляет около 2 КБ, что намного меньше размера страницы (4 КБ). Поскольку таблица упорядочена по идентификатору, очень вероятно, что все эти записи помещаются на 1 странице, максимум на 2, и поэтому для чтения всех 10 записей требуется всего пара чтений.
Теперь предположим, что размер строки больше (скажем, 2 КБ), тогда общий размер всех этих записей теперь составляет 20 КБ. Минимальное количество необходимых чтений теперь составляет как минимум 5, возможно 6. На занятом сервере базы данных эти чтения приводят к дополнительным операциям ввода-вывода и дополнительной нагрузке на память в cahce.
крупные объекты
В зависимости от объема хранимых данных поля больших объектов и переменной длины (например, VARCHAR) могут хранить данные на отдельных страницах, либо на страницах больших объектов, либо на страницах с переполнением строк.
Что это значит? Если у вас есть таблица с множеством таких столбцов, и вы выполняете запрос SELECT * ..., то SQL Server должен извлечь все эти дополнительные страницы, чтобы прочитать все эти дополнительные данные. В итоге получается та же ситуация, что и выше - много операций чтения, что плохо .
Однако, если вместо этого мы указываем только некоторые столбцы в нашем запросе, например, SELECT ID, Address ... тогда SQL Server не нужно беспокоиться о чтении страниц, которые содержат данные, которые нам не интересны. Несмотря на то, что эта таблица может определять много столбцов с огромной шириной строки, потому что мы указали интересующие нас столбцы и поскольку эти данные хранятся на отдельных страницах, количество операций чтения все еще относительно низкое.