2010-11-02 1 views
1

То, что я ищу, это вернуть некоторую оценку количества строк, а не фактический счет, который может быть дорогостоящим вызовом. Подобно тому, что вы видите в поиске Google (... от около 1.000 строк).Как получить результат count как 'about xx rows'?

Есть ли какие-то готовые решения для этого? Если нет, каков общий подход?

Я запрашиваю базу данных Sql Server 2008.

EDIT: Чтобы уточнить, количество результатов относится к определенным пользовательским запросам. Например, пользователь ищет «Джон», и результат должен быть «Есть около 1.280.000 строк, которые соответствуют Джону»

+2

Следует помнить, что оператор подсчета относительно недорог из-за сложного дерева, такого как структурирование, используемое SQL Server. Если вы подсчитываете строки одной таблицы, затраты на обход дерева зависят от количества строк, но в целом очень эффективны. –

+0

Это дорого из-за объединения очень больших таблиц и несколько сложного выражения «где». – veljkoz

+0

@veljkox: Если это так, вы можете захотеть запустить профилировщик SQL Server, когда запускаете свои запросы и подсчитываете, чтобы получить статистику производительности. Затем вы можете запустить их через советник по настройке сервера sql, который, вероятно, предложит соответствующие индексы, которые могут значительно увеличить производительность по сравнению с большими объединениями и большими наборами данных. –

ответ

1

Трудно сказать, что вы просите. Если вы говорите о возврате числа из алгоритма поиска, вы можете вычислить хэш из входов, а затем использовать этот хеш для сопоставления с подсчетом, который вы периодически поддерживаете так часто. Это может дать вам «правильные результаты» в зависимости от того, насколько хорош хэш и как часто вы обновляете свои счета.

+0

Хорошо, у этого есть потенциал, но есть ли у вас другие указатели, как это сделать? Если у нас есть строка поиска, которая может вырасти до 200 символов, нам нужно будет обновить статистику для каждой комбинации символов, что далеко не эффективно ... и не говоря уже о том, что у нас есть и другие критерии. – veljkoz

1

См. Мой комментарий выше. Однако, если вы обнаружили, что операция подсчета особенно дорого там, как представляется, способ, чтобы определить число строк, используя следующее:

SELECT rows FROM sysindexes WHERE id = OBJECT_ID('sometable') AND indid < 2 

Это было взято от предыдущей публикации, расположенного здесь:

Is count(*) really expensive?

1

Общий подход состоит в том, чтобы взять случайный образец строк, чтобы оценить, сколько их действительно существует. Например, если ваши идентификаторы были UUID, тогда вы можете выполнить фильтр в своем предложении select, который создаст случайную выборку. Поэтому вы можете просто посмотреть строки с идентификатором, начинающимся с «f». Затем умножьте счет на 16, чтобы получить оценку количества строк. Вам нужно будет создать индекс для этого, чтобы быть быстрым, хотя.

+0

Если производительность затруднена множественным соединением на нескольких больших таблицах, тогда путь выполнения может выполнить почти всю работу, требуемую до определения того, как возвращать строки, начинающиеся с «f». Ваше решение может соответствовать некоторым сценариям, но лучше всего знать, что это может быть неуместным в зависимости от схемы и объединений. –

5

Просто добавить дикую карту к существующим предложениям ...

Если ваша статистика довольно актуальной, одна потенциальная идея была бы проанализировать предполагаемый план выполнения из кода вызова (так ограничение здесь это включает код за пределами SQL для получения & анализ XML)

eg

SET SHOWPLAN_XML ON; 
SELECT Something 
FROM MyTable 
WHERE SomeField = 'ABC123' 

Затем проверьте возвращенный XML, чтобы вытащить значение «EstimateRows».

+0

это хорошее решение, но есть ли где-нибудь, что количественно, что попытка сгладить «EsimateRows» - это меньше, чем обычное выполнение «счет»? –

+1

+1 для неортодоксальной идеи! :) Я не думал об этом, но, к сожалению, оценочные строки очень грубо оцениваются в плане выполнения, делая ошибки для миллионов строк, что мы не можем предоставить в качестве информации для пользователя. но спасибо! – veljkoz

+0

@Brian Scott - подсчет рассчитывается на основе статистики в процессе формирования плана выполнения, поэтому не нужно уходить и «касаться» данных - все это делается на этапе предварительного исполнения. Для сценариев, в которых COUNT оказывается дорогостоящим, ускорение может быть достигнуто для вычисления плана выполнения, а не для выполнения полного запроса. Дайте ему вихрь на большой таблице – AdaTheDev

0

Vlejkoz, на основе ваших дальнейших обновлений, похоже, что вы ищете алгоритм обычного текстового поиска, а не то, что я думаю, это ваши текущие дорогие таблицы поиска и объединения.

В SQL Server у вас есть полная структура для этого, это называется полнотекстовым поиском Microsoft и предоставляет дополнительные возможности для запросов. Это дает вам синтаксис поиска, гораздо более похожий на традиционный поиск нечеткого стиля Google, но taylored торгует вашими конкретными таблицами базы данных.

Там много к теме, так лучше, что вы посмотрите на этой вводную статье, которая, кажется, встретить похожее требование к вашему вопросу:

Microsoft Full Text Search article

+0

Мы исследовали это и обнаружили, что выражения: «like»% abc [df] _e% '"не поддерживаются, что нам и нужно ... – veljkoz

1

Раздельного к моему другому ответу, как это совершенно другой ответ, который вы можете использовать только из TSQL ....

Другой возможностью было бы использовать предложение TABLESAMPLE, чтобы посмотреть только на указанное число (или процент) страниц данных, а затем умножить это.

например.

SELECT COUNT(*) 
FROM MyTable TABLESAMPLE(50 PERCENT) 
WHERE SomeField = 'ABC123' 

Тонкая настройка размера выборки потребуется. Я рекомендую прочитать полный текст через BOL reference, поскольку это может быть очень полезно.