Цитата:
Сообщение от
AndyD
И, как правильно выше заметили - это не значит, что SQL не будет напрягаться и хранить результат, если запрос связан с сортировками/группировками/объединениями
Похоже таки надо сказать несколько слов по поводу сортировок и "напрягаться".
определения:
- MS SQL хранит данные экстентами, которые состоят из 8Кб-страниц. MS SQL отравляет на диск команду чтения/записи для всего экстента. меньшими порциями MS SQL дисковые операции не делает.
- данные (record) хранятся в страницах. в каждой 8кб странице умещается несколько строк (record). В частности это означает, что максимальный объем хранения в одной записи в MS SQL - 8Кб
- индекс - это маленкая запись ))) Да с натяжкой, но в данном случае отличия не важны. Важно, что индексы также хранятся в страницах. столько индексов, сколько уместится на страницу.
- индексы как правило (Бггг!) отсортированы, и с огромной вероятностью нужные для выборки строки индекса хранятся рядом на одном экстенте.
- для сортировки MS SQL все равно прочтет с диска экстенты с индексами. Прочтет в любом случае (почти в любом - есть кластерные индексы, есть покрывающие индексы)
- важно! размер индекса как правило существенно меньше размера записи. обычно индексы содержат поля, сумма которых 60-200 байт. А размер записи с данными легко может составлять 1000-3000 байт. см. vendTrans, см. InventTrans, inventSellement.
собственно проблема:
- после сортировки, после того, как SQL определил какие записи нужно вернуть, для выдачи результатов в Аксапту MS SQL будет читать экстенты с записями (record). МНОГО. поскольку сами записи больше и раскиданы по разным экстентам, операций чтения данных будет много.
- поскольку прочитанные данные (record) достаточно объемные, СКЛю нужно очень много "временной" памяти, чтобы хранить полученные результаты и выдать их в Аксапту при следующем QueryRun.next
- да, вроде должен использоваться курсор... но... есть счетчики и мониторинг в СКЛ, который позволяет увидеть, что большую часть времени для алгоритмов типа "сопоставление" SQL читает экстенты с данными впустую. По крайней мере, у меня сложилось стойкое впечатление, что это так.
еще раз:
- экстенты с индексами все равно будут прочитаны )))) даже не беспокойтесь об этом
- число читаемых с диска экстентов в индексами в разы, на порядки меньше числа экстентов с данными (это сделано специально, в этом и суть индексов
)
- беспокоит число операций чтения самих данных, которые SQL готовит для отдачи Аксапте.
- суть paging в том, что SQL хранит у себя ссылки на данные (небольшой объем памяти), а сами данные читает по мере запроса страниц. Причем программист может управлять размером порции, которая готовится SQL'ем и отдается в ответ на запрос.
В операциях, которые делают выборку, по каким-то бизнес-условиям забирают несколько записей из выборки и изменяют выборку (операции типа сопоставление)...
в таких операциях хотелось бы использовать управляемый paging.
собственно отсюда и вопрос - У кого есть опыт работы с paging-методами в Query? Стоит ли этим заморачиваться?
в частности, даст ли гемор с pagin'ом лучший результат, чем автоматическая работа с однонаправленным серверным курсором?