Производительно Content Query Web Part

Недавно столкнулись вот с чем: Заказчик начал жаловаться, что страничка, на который аггрегируются новости из нескольких источников (хранящиеся в списках) загружаются очень долго. Для отображения и запроса элементов использовались несколько слегка модифицированный веб-частей "Запрос содержимого"(Content Query Web Part). Данные собирались с нескольких (около 10) списков, каждый их которых жил на своем узле. Время загрузке страницы иногда достигало 20 секунд, хотя время-от времени происходило мгновенно. Почему загрузка могла происходить очень быстро стало понятно - сразу работал кэш объектов, некоторое время хранящий результаты запроса. А вот поиск причины медленной работы занял два дня. Как оказалось, в результате некоторых организационных просчетов на production-сервере заказчика оказался список размером в 900 тыс, забитый практический бесполезной информацией. А все списки SharePoint хранитв одной таблице AllUserData, размер который разросся до 1 800 000 записей. Каждый запрос к ней, которых страничка делала по числу списков занимал около секунд, а 90% времени в каждом запросе - поиск по инждексу, даже несмотря на то, что то был Clustered Index Seek. Решение напрашивалось простое - удалить огромный список и все. Но и здесь возникли сложности - при попытке его удаления веб-приложение портала обрушивалось. Причина вноь оказалась на SQL сервере - при удалении, перемещение списка в корзну вызывалось попытку выполнить 900 тысяч INSERT в одной транзакции, чего бедный сервер, конечно не выдерживал. Только отключение корзины (кстати, это удобнее делать через stsadm) решило проблему