есть ли что-то более быстрое, чем подсчет для больших таблиц?

количество (идентификатор_предложения) > 100;

С этим есть проблема... Либо в таблице есть повторяющиеся пары слово/предложение, либо нет.

Если в нем есть повторяющиеся пары слово/предложение, вы должны использовать этот код, чтобы получить правильный ответ:

HAVING COUNT(DISTINCT Sentence_ID) > 100

Если в таблице нет повторяющихся пар слово/предложение... тогда вы не должны считать id_предложений, вы должны просто считать строки.

HAVING COUNT(*) > 100

В этом случае вы можете создать индекс только для word_id для оптимальной производительности.

Если у вас его еще нет, создайте составной индекс для id_предложения, id_слова.

Если этот запрос выполняется часто, а таблица редко обновляется, вы можете сохранить вспомогательную таблицу с идентификаторами слов и соответствующими счетчиками предложений — трудно придумать какую-либо дальнейшую оптимизацию помимо этого!

Ваш запрос в порядке, но для получения более быстрых результатов требуется небольшая помощь (индексы).

У меня нет своих ресурсов под рукой (или доступа к SQL), но я попытаюсь помочь вам по памяти.

Концептуально единственный способ ответить на этот запрос — подсчитать все записи, которые имеют один и тот же word_id. Это означает, что механизму запросов нужен быстрый способ найти эти записи. Без индекса по word_id единственное, что может сделать база данных, — это просмотреть таблицу по одной записи за раз и продолжать подсчитывать итоги для каждого отдельного найденного слова word_id. Обычно для этого требуется временная таблица, и никакие результаты не могут быть отправлены, пока вся таблица не будет просканирована. Нехорошо.

С индексом для word_id ему все равно придется проходить через таблицу, так что можно подумать, это мало поможет. Однако механизм SQL теперь может вычислять количество для каждого word_id, не дожидаясь конца таблицы: он может отправить строку и количество для этого значения word_id (если оно соответствует вашему предложению where) или отбросить строку (если это не так); это приведет к меньшей нагрузке на память на сервере, возможно, частичным ответам, и временная таблица больше не понадобится. Второй аспект — параллелизм; с индексом word_id SQL может разделить задание на части и использовать отдельные ядра процессора для параллельного выполнения запроса (в зависимости от возможностей оборудования и существующей рабочей нагрузки).

Этого может быть достаточно, чтобы помочь вашему запросу; но вам придется попытаться увидеть:

CREATE INDEX someindexname ON sentence_word (word_id)

(Синтаксис T-SQL; вы не указали, какой продукт SQL вы используете)

Если этого недостаточно (или совсем не помогает), есть два других решения.

Во-первых, SQL позволяет предварительно вычислить COUNT(*) с помощью индексированных представлений и других механизмов. Деталей под рукой нет (да и делаю я это нечасто). Если ваши данные не меняются часто, это даст вам более быстрые результаты, но с затратами на сложность и немного места для хранения.

Кроме того, вы можете захотеть сохранить результаты запроса в отдельной таблице. Это практично только в том случае, если данные никогда не меняются или изменяются по точному графику (скажем, во время обновления данных в 2 часа ночи), или если они меняются очень мало и вы можете жить с неидеальными результатами в течение нескольких часов (вы придется запланировать периодическое обновление данных); это моральный эквивалент хранилища данных бедняка.

Лучший способ узнать наверняка, что работает для вас, — запустить запрос и посмотреть план запроса с некоторыми индексами-кандидатами, такими как приведенный выше, и без них.

Удивительно, но для больших наборов данных это можно сделать еще быстрее:

SELECT totals.word_id, totals.num 
  FROM (SELECT word_id, COUNT(*) AS num FROM sentence_word GROUP BY word_id) AS totals
 WHERE num > 1000;