SQL Server - лучший тип данных для хранения большого строкового значения

Question

у нас есть таблица базы данных, которая содержит около 200 000 записей. который включает в себя 3 текстовых столбца, которые содержат строковые данные длиной от 4000-70000. но простой выбор в таблице занимает более 1 минуты, чтобы вернуть данные. и даже используя условие where и индексы для выбора 12000 записей для условия, это занимает 40 секунд.

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

Answer 1

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

• У ваших таблиц есть индексы? Вы их используете?
• Достаточно ли у вас пропускной способности?
• Используются ли на ваших сетевых картах самые последние драйверы?
• Проанализировали ли вы план выполнения запроса?
• Ваш SQL-сервер находится в состоянии стресса (процессор / память / диск)? А твой веб-сервер / рабочий стол?
• Правильно ли нормализованы ваши данные?

Answer 2

Вы должны сделать столбцы nvarchar вместо ntext, и вы сможете включить их в индекс как неключевые столбцы. Но ... это много данных, которые вы выбираете. Если вам нужно выполнять запрос так часто, что время выполнения составляет 1 минуту, возможно, вам следует переосмыслить свой подход.

Answer 3

Если вы не хотите перемещать столбец ntext в другую таблицу, убедитесь, что вы не извлекаете эти столбцы до самого последнего прохода. Так что вместо этого:

SELECT * FROM tbl WHERE (/* your code here*/)

Попробуйте что-то вроде этого:

SELECT * FROM tbl WHERE id IN (SELECT id FROM tbl WHERE /* your code here */)

Answer 4

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

Переместите текст в отдельную таблицу с собственным первичным ключом и используйте эти три в качестве внешних ключей в исходной таблице.

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

(В качестве примечания) еще одно преимущество заключается в том, что есть вероятность того, что вам не обязательно отображать весь этот текст на экране для всего возвращенного набора результатов за один раз - так что вы в конечном итоге получаете только Конкретные текстовые данные, которые вам нужны.

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

Answer 5

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

Answer 6

для вашего второго запроса, он может передать более 4,6 гигабайта, так что я могу видеть, что это занимает потенциально много времени ...

для запроса с одной записью, вы можете попробовать разбить его на столбцы фиксированной длины:

есть. часть 1 nchar (2000), часть 2 nchar (4000), часть 3 nchar (8000), часть 4 nchar (16000) ...

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

если вы "Показать план выполнения" в Query Analyze, появится что-нибудь полезное ...?