Производительность SQL nvarchar

Question

Я храню локализованные строки в одной таблице данных, используя MS Sql (2008 или что-то еще). Большинство строк короткие и могут быть представлены с помощью varchar (200), в то время как около 10% гораздо дольше требуют чего-то вроде varchar (5000). Мой вопрос: есть ли преимущество в производительности при получении более коротких строк, если я разбью это на две таблицы, подобные этой:

CREATE TABLE ShortTextTable(ID bigint IDENTITY(1,1) NOT NULL, TextValue nvarchar(200))
CREATE TABLE LongTextTable(ID bigint IDENTITY(1,1) NOT NULL, TextValue nvarchar(4000))

Против:

CREATE TABLE TextTable(ID bigint IDENTITY(1,1) NOT NULL, TextValue nvarchar(4000))

Эти данные будут редко обновляться, меня действительно беспокоит только чтение.

Answer 1

Это зависит. Может быть преждевременная оптимизация.

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

Кроме того, он разбивает пространство, которое логически является одним пробелом, и более не будет управляемым как одно пространство (то есть добавит индекс в обоих местах и ​​т. Д.)

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

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

Answer 2

Нет, реального выигрыша нет. Чтобы увидеть узкие места из-за чередования размеров строк, особенно base don int int, это было бы настоящей крайностью.
С другой стороны, беспорядок работы с такой схемой хранения очень понятен и присутствует: вы должны решить, исходя из длины строки , которую вы еще не получили , на какую таблицу смотреть! Вы, вероятно, в конечном итоге будете искать методом проб и ошибок (попробуйте одну таблицу, затем другую), что гораздо более затратно, чем любая проблема структуры хранения таблицы nvarchar.

Answer 3

Нет или отрицательное усиление,

Хранение мудрое: Строка переменной длины хранится в виде числа символов + 2 байта для длины. Итак: длина данных одинакова, но у вас будут издержки индекса и ключа 2-й таблицы.

Мудрая обработка:

• решает, к какой таблице добавить его
• исправление опечатки означает, что она не в той таблице (игнорируя ptrs и т.д.)
• работа с уникальностью ключа для 2 таблиц (если у них будет общий родитель)

Теперь, что более важно, я видел, что вы упомянули локализацию, но вам нужен nvarchar? Еще один вопрос: производительность varchar против nvarchar

Answer 4

В SQL 2005, и я считаю, что в 2008 году вы не создадите NVarChar (5000), поскольку вы превышаете размер страницы с таким типом данных, NVarChar (Max) будет работать на этом этапе. При указании числа N для nVarChar у вас есть ограничение до 4000.

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