Запрос типа:
SELECT at.T, aa.A, Cnt FROM (SELECT T_id, A_id, COUNT(*) AS Cnt FROM (SELECT T_id, A_id FROM audio limit 8000000) a  GROUP BY A_id, T_id HAVING Cnt>1 ORDER BY Cnt DESC LIMIT ".$n.") q1
           INNER JOIN a_T at ON q1.T_id=at.id
           INNER JOIN a_T aa ON q1.A_id=aa.id

На A_id, T_id есть составной индекс, который работает)
Во внутреннем запросе есть число, которое я и изменяю. Картина следующая:
500к - 0.36
1кк - 0.77
2кк - 1,7
4кк - 3,44
8кк - 62

Первый раз запрос с 4кк тоже выдал 60 секунд, но повторные начали выполняться за 3,44.

Куда копать, может кто знает?)

Во второй раз работает быстрее, так как СУБД использует кэш. Возможно, при 8К СУБД просто не делает и не использует кэш, так как иначе забьется вся оперативная память.

Грусть.. А я уже обрадовался, что запросы достаточно быстро выполняются.
Спасибо

(2) Возможно, если покрутить настройки СУБД, то она даст такой большой кэш. Но я лично, не знаю что именно делать, может тут http://sql-ex.ru/ прольют свет на проблему.

Запрос какой то извратный. Попахивает отсутствием понимание что и как храним и для чего.

(4) да это эксперимент, имхо, рабочий запрос не надо в ветку выкладывать - там поди от 100 строк

(4) А что извратного то? Да, первый селект может лишний, а так всё норм - обычный селект с джойнами

пиши запросы в 1с форматировании, а то же нихрена не понятно про что там

(0) в подобных вопросах принято показывать планы запроса у хорошего и плохого вариантов...

(8) Планы?

(0) запрос говно и дело не в индексах.
1. Используй временные таблицы.
2. Нафига, вот нафига в самом внетреннем запросе выгребать все данные, если тебе нужны только DISTINCT?
3. Зачем два inner join с одной и той же таблицей? Один надо удалить и, если она не большая, то это соединение имеет смысл перенести в самый внутренний селект, где 8 млн

1. Это может сократить время в моём случае? Что-то сомневаюсь
2. Там итак все различные (по построению таблицы)
3. Таблицы разные - описался, когда на форум вставлял
Какой смысл переносить соединение внутрь вообще? Если на входе миллионы строк, а на выходе до 1000?

(9) да, планы, не знакомые слова что ли?

(12) Планы таблиц не знакомы)

Или это озночает состав?
Все id - int
Через соединение VARCHAR прикрепляю

sql serv использует не только кэш, но и статистики.
1. 60 сек на запрос это много.
2. Зачем здесь нужен OrderBy?

(0) Переписать запрос

Более того, переписывать структуру и обслуживающий персонал менять)

Для начала выкинь нах свой самый внутренний запрос на 8 млн

(15)
1. Знаю)
2. Нужно отсортировать по популярности

(16) Да как его переписать - он и так примитвнейший
(17) Над структурой думал, но размер базы вырастет минимум в 10000 раз

(18) Чтобы я по десять минут ждал?

Чего ваяешь?
Работаешь со своей структурой данных или лезешь в чужую?
Засыпал всех каверзными вопросами, может просто почитать-подумать?

(19) а ты запрос наваял чтоб чтото осмыленное получить или хоть бы, главное быстро?)
Без знания природы полей, колва значений их, дисперсии и прочего, можно лишь посоветовать ТСу сидеть в конфигураторе 1с и не рыпаться

(20) Своя структура.
Ваяю сайт. Суть такова: есть люди, у них есть "предпочтения" (предпочтение = комбинация двух значений id, по которым и группирую). Таблица имеет вид:
id1, id2, user_id

У пользователя в среднем 200 предпочтений

Нужно найти самые популярные предпочтения

(21) Осмысленное конечно) И быстр надо