#sql #sql-server #indexing #relational-database
#sql #sql-сервер #индексирование #реляционная база данных
Вопрос:
У меня есть таблица транзакций (единый первичный ключ) с миллионами записей, и каждый день добавляются 100 записей.
Затем эта таблица дополнительно используется при согласовании и расчете, которые выполняются только для вновь вставленных записей, без какого-либо порядка.
Хотя я создал кластеризованный индекс в столбце ID, но не уверен, должен ли он быть ASC или DESC. Поскольку большая часть обработки выполняется для вновь вставленных записей, я думал заказать индекс как DESC, но не уверен.
Я уже проверил несколько блогов и вопросы по StackOverflow об этом, но все они обсуждают составной кластеризованный индекс с предложением order by . В моем случае существует кластеризованный индекс с одним столбцом и нет требований к порядку by.
Комментарии:
1. Это не имеет значения, SQL Server может просматривать индекс с первой или последней страницы с одинаковой эффективностью.
2. Спасибо @RogerWolf за комментарий. Не могли бы вы поделиться какой-нибудь ссылкой или более подробной информацией об этом.
3. Я не думаю, что вы подберете эти «недавно добавленные» записи с помощью запроса типа
select top (1000) * from dbo.Transactions order by Id desc. Если вы это сделаете, вы можете забыть о параллельной обработке и любой эффективности в целом. Вместо этого вы посмотрите на некоторое поле, которое показывает, на каком этапе рабочего процесса транзакция находится в данный момент. И вам понадобится индекс в этом поле, поверьте мне. В этом случае порядок вашего кластеризованного индекса не имеет значения.4. Я думаю, вы правы. Спасибо, что поделились своими мыслями.
Ответ №1:
Это зависит… Для некоторых операций, таких как ORDER BY, это не имеет значения, поскольку индекс является двунаправленным, поэтому сортировка не требуется.
Но для других операций, таких как ранжирование, сканирование индекса и т. Д., Это имеет значение. Механизм SQL предназначен для выполнения прямого сканирования индекса с параллелизмом, но если оптимизатору запросов требуется обратное сканирование индекса, такая операция является однопоточной. Таким образом, это может повлиять на производительность, если вы выберете неправильный порядок сортировки.
Это действительно зависит от данных и запросов в вашей базе данных, поэтому я предлагаю фиксировать наиболее частые запросы пользователей (по этой таблице) и проверять их планы выполнения и статистику ввода-вывода для двух разных порядков сортировки.
Также это может привести к фрагментации индекса, если данные добавляются не в том порядке, в котором порядок сортировки индекса.