таблица разделов azure synapse - без повышения производительности

одна из таблиц синапсов имеет 300 миллионов строк и продолжает увеличиваться. Каждая строка как столбец состояния, т.е. active_row либо 0, либо 1. Active_row имеет тип данных int. Пользователи запрашивают только active_row = 1, который имеет только 28 миллионов строк, а остальные данные, то есть 270 миллионов, неактивны. Чтобы повысить производительность и избежать полного сканирования таблиц на active_row, я преобразовал таблицу в таблицу разделов на active_row, как показано ниже.

CREATE TABLE [repo].[STXXXXX]
WITH
(
    DISTRIBUTION = ROUND_ROBIN,
    CLUSTERED INDEX (
        [ID] ASC
    ),
     PARTITION
    (
        active_Row RANGE LEFT FOR VALUES  (0,1)
        )
)
as
select * from repo.nonptxx;

Пользователи сообщили, что после перехода к таблице разделов производительность не улучшилась. когда я проверил приведенный ниже запрос, то есть раздел и не разделение, я не вижу никакой разницы в простом объяснении запроса с точки зрения предполагаемого поддерева, операции и т.д., и вся статистика остается той же цифрой. Из sys.dm_pdw_nodes_db_partition_stats я вижу 3 раздела, созданные на разделе 1, имеющем 270 миллионов данных, разлитых в 60 узлах, и раздел 2 из 60 узлов, 30 миллионов разлитых узлов, а раздел 3 из 60 узлов пуст.

select * from  [repo].[STXXXXX] where active_row =1

vs

select * from repo.nonptxx where active_row =1

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


sql azure-synapse azure-sql-data-warehouse
person baba    schedule 18.01.2021    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Статистика обновляется?

Запустите ОБНОВЛЕНИЕ СТАТИСТИКИ [schema_name]. [Table_name] и повторно запустите свои тесты (ИЛИ создайте статистику, если она не существует).

Вы должны увидеть шаг Фильтр с меньшим количеством строк, возвращаемых при запросе одного раздела в плане запроса tsql сразу после шага Получить. Вы не увидите его в плане запроса dsql. Вы не увидите никакой стоимости поддерева для Select *, которое преобразуется в одну операцию возврата из отдельных узлов, однако вы увидите, что расчетное количество строк на выполнение становится меньше по мере фильтрации по разделам (с актуальной статистикой) . Отсутствующая или устаревшая статистика может привести к странным результатам плана запроса, потому что оптимизатору, по сути, не хватает информации для принятия правильного решения ... следовательно, это непредсказуемые, а иногда и плохие результаты.

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

person Miles Cole    schedule 11.03.2021