fed: Ledger Balance Data in DAX

[fed]

Цитата:

Сообщение от glibs

А вот если бы индекс был некластерный, то записи будут лукапиться последовательно (сначала будет сканироваться кусками индекс, а потом будут лукапиться уже данные). В случае с кластерным индексом каждая страница с данными гарантировано считается только один раз (оптимально). А в случае с лукапом по индексу одна и та же страница может считаться много раз (зависит от ресурсов памяти, которыми располагает сервер БД и насколько много сессий он обслуживает и какую нагрузку они ему обеспечивают). Если весь LedgerTrans поместится в кеше, то запрос может и быстро отработать, но если пользователи-конкуренты его в момент запроса сильно нагрузят, то памяти на кеш на всех может не хватить, и будет прилично ввода-вывода.

Не совсем так. MS SQL прочитает из страниц некластерного индекса rowId страниц с данными (то есть - сочетание номер файла:номер страницы:смешение в странице), отсортирует по файлам и страницам и начнет читать. Каждая страница будет прочитана один раз. (Насчет нехватки памяти - один rowId то ли 10 то ли 12 байт памяти занимает, вряд ли памяти в систем не хватит, даже если идет чтение 10 миллионов записей). Тут правда, действительно, есть одно "но": Если по кластерному индексу у нас надо выбрать 60% записей, то система 60% страниц и прочитает. А вот по таблице с heap-org, с большой вероятностью данные из этих 60% записи разбросаны по всем станицам и запрос выльется в fullscan.
[/QUOTE]

Цитата:

Сообщение от glibs

Я говорил про стандартные индексы. На все случаи жизни индексов не настроишь. Индексирование — дело разумного компромисса.

Ну да - согласен.

.

Цитата:

Сообщение от glibs

О чем идет речь?

Ну если у тебя по таблице есть кластерный индекс, то все остальные индексы содержат не rowId, а значение ключа кластерного индекса. Поскольку ключ в стандартном ledgerBalancesDimTrans длинный, то размер индексной запси (ключ некластерного индекса+ключ для поиска по кластерному индексу) будет заметно больше. Длинее индексная запись - меньше индексных записей в странице. Меньше индексных записей в странице - выше дерево. Выше дерево - больше операций чтения.
Кроме того - если я отбираю в некластерном индексе те же 60% записей, то опять таки может сложится ситуация при котором эти 60% записей раскиданы по всем страницам кластерного индекса. И все это выльется в итоге в фулл-скан.

Так что для того чтобы кластерный индекс был действительно эффективным, надо чтобы большая часть поисков (ну то есть - эдак процентов 70 хотя бы) выполнялось всегда по одному и тому же ключу. Это хорошо выполняется для custTable, например а вот для LedgerBalanceDimTrans - не выполняется, поскольку фильтрация всегда идет по сочетанию Счет+некий набор аналитик. Просто я тут наблюдал как работает некоторое специализированное распределение счетов, в которой автор как раз использует ledgerBalancesDimTrans, и для разных видов затрат задает разные фильтры по аналитикам. Так вот - индекс использовался только для фильтрации по номеру счета+дата.