Оптимизация таблиц SQL Server 2000

Question

Я целый день работал над оптимизацией таблицы базы данных SQL Server 2000 с ~ 9 миллионами строк. Мой единственный опыт работы с БД был с таблицами с несколькими сотнями строк, поэтому мне никогда не приходилось иметь дело с оптимизацией.

Я делаю выборки и обновления на основе 21-значного числа.

Используя индексированный тип char (21), запросы занимают более 2 секунд, а процесс SQL Server занимает 1,5 гигабайта оперативной памяти и 100% процессора.

При индексированном типе bigint мои запросы занимают несколько миллисекунд, а процесс занимает ~ 100 МБ оперативной памяти.

Я просто хочу понять, что здесь происходит, это нормально, или есть определенный способ индексации типа символа для лучшей производительности?

Вот некоторые из моих sql:

CREATE TABLE data
(
    tableID int NOT NULL IDENTITY PRIMARY KEY,
    tag char(21) NOT NULL UNIQUE,
    dataColumn1 datetime NULL,
    dataColumn2 char(8) NULL,
    lastModified datetime NOT NULL
)

Параметризованный запрос от c #:

SELECT tag FROM data WHERE tag = @tag;

Спасибо за любую помощь.

Answer 1

Сравнение символов несколько медленнее - необходимо учитывать последовательность сопоставления - не говоря уже о физической разнице в размерах между 21-символьной строкой и bigint (8 байт).Поиск по индексу не может быть настолько эффективным, потому что он должен оценивать каждый байт в ваших значениях char (21), определять порядок сортировки символа, а затем решать, как он сравнивается с соответствующим символом в искомом значении..

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

Answer 2

В этом нет ничего необычного, SQL обрабатывает числа намного лучше, чем символы. Поле bigInt использует 8 байтов, которые аккуратно вписываются в страницу памяти. Поле char занимает 21 байт, что почти в три раза увеличивает объем памяти, чтобы поместить его в индекс.

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

Answer 3

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

SELECT Column
FROM Table
WHERE UPPER(CharColumn) = 'ABC'

Очевидно, я просто догадываюсь, но это типичный источник проблем с производительностью для столбцов char / varchar / nvarchar. Если вы пишете такие запросы, вы должны понимать, что перенос столбца в функцию не позволяет SQL Server выполнять поиск по индексу.

Также примите во внимание количество строк, которые вы фактически возвращаете; 9 миллионов строк не обязательно много в таблице, но даже 100 000 строк - это огромное количество в наборе результатов. Иногда узкое место просто передает все результаты.

Если ничего из этого не описывает вашу проблему, то я предлагаю обновить ваш пост, добавив некоторую информацию о схеме, ваших индексах и медленном запросе. Есть и другие способы оптимизации, которые возможны, хотя SQL Server 2000 уже давно работает, поэтому ваши возможности ограничены.

---

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