Повышение производительности запросов - T-SQL
У меня есть таблица, которая уже упорядочена по столбцу «datetime». Потому что, когда он вставлен, я сохраняю дату UTC, поэтому она упорядочена. Это очень насыщенная таблица. Поэтому я пытаюсь улучшить производительность запросов, если это возможно.
Когда я использую что-то WHERE columnDateTime > dateToSearch, возвращение строк занимает слишком много времени. Поскольку моя таблица уже заказана columnDateTime, что я могу сделать, чтобы улучшить производительность этого запроса. Например, когда таблица упорядочена с помощью cod, и вы пытаетесь найти cod > 40, оптимизация T-SQL остановит поиск, когда найдет cod = 41, и вернет остальную часть таблицы, потому что она знает, что таблица упорядочена по этот индекс. Может ли это способ сообщить T-SQL, что моя таблица уже упорядочена этим columnDateTime?
Стол действительно не заказан. Если бы вы могли заказать, его нельзя было бы заказать двумя разными способами. Проверьте планы запросов.
(1) Вы используете mysql или SQL Server? T-SQL - это версия SQL от Microsoft. (2) В реляционных базах данных концепция «таблица упорядочена по ...» не является точной. Столы нет и не могут быть заказаны вообще. Однако у них есть индексы. И при рассмотрении производительности важно знать детали точный всех ваших индексов. (3) Ваш вопрос - слишком расплывчато, на который нужно ответить: как долго это «слишком долго»? Сказать "очень много" означает ничего такого! (4) Точные запросы действительно имеет значение! Чтение: Как спросить
Когда строки вставлены, есть столбец, в котором хранится дата UTC, когда он был вставлен, и он генерирует код, оба столбца, код и дата UTC уже упорядочены.
@RafaelAndrade Данные НЕ ЯВЛЯЕТСЯ "заказаны" в реляционной базе данных. Он заказывается только предложением ORDER BY в запросе.
@CraigYoung docs.microsoft.com/en-us/sql/relational-databases/indexes/… может быть, читал о кластерных индексах, прежде чем сообщать людям неверную информацию?
Если это SQL Server, может быть логический (не физический) порядок через кластерный ключ / кластеризованный индекс, хотя, как и при любом изменении производительности, для обеспечения руководства требуется запрос + схема + план запроса. Если кластеризованного индекса нет, таблица представляет собой кучу, и, хотя вы можете подумать, что существует порядок, основанный на вставке, SQL Server не может полагаться на этот порядок.
Если вы вставляете строки в строгом хронологическом порядке, а столбец никогда не обновляется, и естественно, что большинство запросов будет фильтровать по нему, он станет хорошим кандидатом на роль (неуникального) кластерного индекса. Но, конечно, вы также можете просто создать для него обычный индекс. Без индекса SQL Server генерирует только статистику о распределении значений в столбце - это некоторая помощь, но не такая большая, как правильные индексы. Он не может использовать какой-либо порядок, который, по вашему мнению, существует, потому что не может гарантировать его наличие.
@AnthonyHancock Может быть, вам следует убедиться, что вы правильно понимать концепцию кластерного индекса, прежде чем заявлять, что я говорю людям «неверную информацию»? Кластерный индекс по-прежнему имеет данные, разбросанные НЕУПОРЯДОЧЕННЫЙ по различным страницам на диске, а может использует кластеризованный индекс для извлечения данных в определенном порядке. Оптимизатор решает, использовать ли кластерный индекс таким образом. на основе запросов, индексов и статистики таблиц.
@AnthonyHancock В любом случае думать о «упорядоченных данных» в РСУБД - подозрительно. Добавьте, что OP очень не понимает, что, по его мнению, означает «заказанный»; и я думаю, что вы оказываете ему медвежью услугу, поощряя небрежное мышление.
@CraigYoung Достаточно справедливо, моя точка зрения заключалась в том, что есть порядок на уровне страницы, но это, очевидно, неоднозначно при рассмотрении всей таблицы данных. Оба из них не имеют значения, если есть полное отсутствие понимания какой-либо индексации и мышление, что вычисляемое поле каким-то образом по умолчанию является порядком таблицы.
Ребята, извините за вопрос новичка. Прежде чем задать вопрос, мне нужно было узнать немного больше о кластерных индексах. Спасибо за поддержку
Ответы 1
Вставка данных по порядку не означает, что они сохраняются по порядку. Не вдаваясь в технические подробности и для повышения производительности:
Создайте
CLUSTERED INDEXна этом столбце. Это требует, чтобы в вашей таблице нет других кластеризованных индексов и у нее нетPRIMARY KEY(или у нее естьNONCLUSTERED, который не используется по умолчанию). С кластеризованным индексом механизм выполняет сканирование индекса (а не полное сканирование таблицы) при фильтрации с помощью> datetimeValueи не нуждается в доступе к дополнительным страницам для данных, поскольку кластеризованный индекс оставляет находятся данных.Создайте
NONCLUSTERED INDEXна этом столбце. Никаких ограничений на этот пункт (по крайней мере, для этого случая), но для каждого совпадения с вашей отфильтрованной датой движку потребуется доступ к другой странице с запрошенными столбцами, если вы неINCLUDEих при создании вашего индекса. Имейте в виду, что включенные столбцы увеличит размер индекса и потребуют дополнительных задач обслуживания, таких как, например, изменение включенного столбца.
Помимо этого, вам следует проверить свой план запроса; если у вас есть соединения, вызовы функций или дополнительные условия, механизм SQL может не использует индексы, даже если они существуют. Есть много вещей, которые могут замедлить выполнение запроса, вам нужно будет опубликовать полный план выполнения запроса (для начала), чтобы проверить детали.
Вы можете использовать этот запрос, чтобы проверить, есть ли в вашей таблице индексы:
DECLARE @table_name VARCHAR(200) = 'YourTableName'
SELECT
SchemaName = SCHEMA_NAME(t.schema_id),
TableName = t.name,
IndexName = ind.name,
IndexType = CASE ind.index_id WHEN 0 THEN 'Heap' WHEN 1 THEN 'Clustered' ELSE 'Nonclustered' END,
Disabled = ind.is_disabled,
ColumnOrder = ic.index_column_id,
ColumnName = col.name,
ColumnType = y.name,
ColumnLength = y.max_length,
ColumnIncluded = ic.is_included_column
FROM
sys.indexes ind
INNER JOIN sys.index_columns ic ON ind.object_id = ic.object_id and ind.index_id = ic.index_id
INNER JOIN sys.columns col ON ic.object_id = col.object_id and ic.column_id = col.column_id
INNER JOIN sys.tables t ON ind.object_id = t.object_id
INNER JOIN sys.types y ON y.user_type_id = col.user_type_id
WHERE
t.is_ms_shipped = 0 AND
t.name = @table_name
ORDER BY
SchemaName,
t.name,
ind.name,
ic.index_column_id
Вы должны убедиться, что есть хотя бы один индекс, в котором ваш datetimeColumn находится с ColumnOrder = 1, и что он не отключен. Если он уже существует, значит, ваша проблема в другом, и мы не сможем помочь без более подробной информации.
У вас есть правильный индекс на columnDateTime ???