Будет ли использование стратегии прокрутки JDBC для подкачки табличных данных привести к снижению производительности?

Question

В настоящее время у нас есть система, которая отображает табличные данные страницы на экране без какой-либо поддержки подкачки в пользовательском интерфейсе. Он работает на Java 1.5 / Spring JDBC / T-SQL, хранящемся в стеке procs / SQLServer 2000.

При отсутствии возможности пропустить строки в наборе результатов (ограничение SQLServer 2K без использования динамического SQL); Я изучаю возможность, чтобы слой данных выбирал все строки, а слой DAO прокручивал пропущенные страницы строк, а затем считывал только строчные строки.

Мой вопрос такой:

Какой выигрыш в производительности (с точки зрения ЦП и В / В БД) будет сравниваться с текущим состоянием, в котором возвращаются все строки?

Я знаю, что по проводам между БД и Приложением будет передаваться только одна страница данных, но мне интересно знать, что произойдет внутри СУБД. Предполагая, что план запроса уже кэширован, собирается ли СУБД пропустить обработку первых 40 страниц результатов, если мне нужна только страница 41?

Полагаю, мне нужно знать, понесем ли мы большие расходы, даже если курсор пропустит первые x страниц набора результатов.

Answer 1

Если у вас есть BTree (индексированный, кластеризованный или некластеризованный), то единственный способ перейти на страницу X - это узнать ключ на странице и сразу перейти к нему. Каждое другое средство «пропустить» первые страницы X-1 должно пройти все страницы от 1 до X и пропустить каждую запись в отдельности.Узкий индекс в поле «постраничный» может помочь подсчитать, так как слоты высокой плотности (отсюда и узкий индекс) уменьшают количество страниц, которые нужно сканировать, чтобы найти строку, которая начинает страницу X.

Answer 2

Почему бы не использовать юнит-тест для получения некоторых чисел.

Итак, вы начинаете с текущей настройки и имеете 5 тестов, пропускаете 0, 2, 4, 6, 8 страниц и смотрите, есть лиразница между пропуском 8 и 2 страниц.

Затем, если у вас есть базовая линия, почему бы не использовать динамический SQL и вернуть только интересующие строки.

Напишите другой тест и посмотритечто происходит.

Затем создайте хранимую процедуру, которая выбирает все, но просто возвращает интересующие строки, и проведите еще один тест для этого.Затем попробуйте выполнить тест с идеей DAO, выполняющей фильтрацию.

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

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