Блог

в одной из таблиц 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 я вижу, что в разделе 1 создано 3 раздела, в которых 270 миллионов данных разлито в 60 узлах, а в разделе 2 из 60 узлов 30 миллионов разлито, а раздел 3 из 60 узлов пуст.

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

против

 select * from repo.nonptxx where active_row =1
 

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

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

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

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

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