Voennich>KRoN
Voennich>я не общался с MySQL но если бы это был MS SQL то обязательно добавил индекс
Voennich>create index avia_top_counts_StartCount
Voennich>on avia_top_counts (start,count)
Voennich>и
Voennich>create index avia_top_counts_CountStart
Voennich>on avia_top_counts (count, start)
из приведенных выше SQL statements следует, что единственным критерием поиска есть идентификатор ресурса. В этих условиях никаких других индексов не надо - не поможет. Индекс сужает зону поиска в том случае, если по нему он идет. А здесь в where clause только идентификатор и лежит. В почти каждой приличной СУБД можно посмотреть план выполнения SQL statement - в MySQL этому служит EXPLAIN. Например,
EXPLAIN SELECT ...
Это, кстати стоит делать всякий раз при написании SQL statemet - чтобы посмотреть, что ваше мнение совпадает с мнением СУБД. В более сложных СУБД надо обязательно обновлять статистику и кластеризировать таблицы.
Самый сложный SQL statement из приведенных (и кстати, единственный, который не использует идентификатор рессурса) - это поиск словарный, но поскольку там % стоят и до и после, то индексы тоже не конают - только последовательный линейный поиск. Можно предложить схему и решения этих задач, но надо заводить специальные тригеры и таблицы - скажем, каждое слово попадающее в базу подвергаем обработку - ищем все подстроки длиной 1, 2, 3, ну 4 скажем. Объем таких строк ограничер 1 + N + N2 + N3 + N4, где N количество букв в алфавите (алфавит как абстракция). после этого на каждый такой случай и использовать это как индекс в хэш таблице для получения списка индексов где это слово встречвается. Здесь за счет увеличения таблиц косвенной индексации и связанно-подчиненных SQL statements можно получить значительный выигрыш при больших текстовых объемах.