Ну, вы не можете оптимизировать запрос для определенного набора результатов и оставить запрос для остальных без изменений. Если вы понимаете, о чем я. Я предполагаю, что нужно изменить только один запрос, поэтому вы оптимизируете его для каждого типа пользователей. Поэтому этот сценарий оптимизации ничем не отличается от любого другого. Выясните, в чем проблема; это слишком много данных, возвращаемых? Расчеты занимают слишком много времени из-за объема данных? Где именно причина замедления? Это те вопросы, которые вам нужно задать себе.
Однако я вижу, что вы говорите о медленных страницах профиля. Когда вы думаете, что запрос, который возвращает эту информацию, уже оптимизирован (поскольку он работает на 95%), вы можете рассмотреть некоторую форму кэширования содержимого страницы профиля. Как правило, страницы профиля не должны предоставлять информацию в режиме реального времени.
Кэширование может быть выполнено многими способами, слишком много, чтобы охватить этот ответ. Но, чтобы дать вам один маленький пример; Вы могли бы работать с временной таблицей. Ваш «запрос профиля» возвращает информацию из этой временной таблицы, информацию, которая уже рассчитана. Поскольку этот запрос будет простым, его выполнение не займет много времени. В то же время вы должны периодически обновлять временную таблицу.
Просто пара идей. Надеюсь, они вам пригодятся.
Edit:
Обычный пользователь добавляет около 200 товаров на мой сайт. Эти опытные пользователи добавляют более 10000 предметов.
В их профиле я показываю все
элементы, которые они добавили (вы можете прокрутить
через них).
Очевидной помощью для этого будет ограничение количества результатов внутри запроса или применение формы нумерации страниц (в DAL, а не в UI / BLL!).