[B]Алексей Власов,[/B] - теперь надо смотреть сам запрос, какие части таблицы с псевдонимом BE участвуют в "where" и дальше. У вас проблема в том, что
а) Mysql затрачивает кучу дисковых операций на выборку 261006 строк данных
б) эти данные скорее всего настолько велики по объему, что при выборке создается временная таблица на диске.
Т.е. сначала mysql читает с диска данные, потом туда опять их пишет, потом только отдаёт вам.
Варианты дальнейших действий:
1. возможно переписать запрос, чтобы подвести как можно ближе под индексы, или индексы подвести под запрос - это может уменьшить цифру 261006 (самый "продвинутый" метод, если только возможен)
2. переписать запрос так, чтобы выбирались только нужные поля - тогда размер 1строки результата будет * 261006 - будет меньше, и может получиться обойтись без временных таблиц на диске.
3. примерно посчитать длину строки результата, умножить на 261006 - получиться примерно размер временной таблицы - разрешить создавать такие таблицы в памяти MySQL это параметры
tmp_table_size = xxxM
max_heap_table_size = xxxM
НО возможно высчитанный xxxM будет неприлично велик для системы, всё зависит от размера памяти сервера
[B]update[/B]
Судя по всему BE - это b_iblock_element. У меня длина строки таблицы - 3523 байта, при перемножении получается около 900МБ - примерно такой объем данных проворачивает ваш сервер при запросе. Потому вариант с tmp_table_size и max_heap_table_size получается неудачным.
Если у вас на сервере оч.много памяти и таблица b_iblock_element в innodb, можно еще выставить большой
innodb_buffer_pool_size
может быть 2GB, может бльше, более точно подобрать можно по анализу отношения Innodb_buffer_pool_pages_free к Innodb_buffer_pool_pages_total - чем оно больше, тем дольше в кеше будет висеть b_iblock_element
4. использовать цифру из п.п.3, умножить в несколько раз и сделать такого размера диск в памяти, через tmpfs и указать её как папку для временных файлов MySQL
5. самый простой метод, если актуальность данных выборки не критично - делать выборку раз в XXX секунд по крону, сохранять её результат и показывать "из кеша", или же настроить кеш надолгое хранение выборки
[B]Oleg_,[/B] у меня отключение проактивного фильтра и * улучшило результат в 2 раза, с 14 до 28, APC и eAccelerator вместе - не дружат, а влияние memcached у меня на показатель оказалось невелико. Но вероятнее всего в реальном приложении memcached поможет больше.