Почему некоторый запрос SQL намного медленнее при использовании с SqlCommand?
При запросе к DynamoDB, если вы не задаете ограничения для ключа раздела и ключа сортировки, вы в значительной степени сканируете либо весь раздел, либо всю таблицу. И это дорого. Вы все еще можете выполнить сканирование префикса на 1 поле, используя это поле в качестве ключа сортировки. Вы не можете оптимизировать запрос и ваши расходы в дальнейшем.
Для выполнения полнотекстового поиска вам действительно необходимо токенизировать текстовое поле и построить инвертированный индекс, используя эти токены. Это то, что делает Elasticsearch.
Служба под названием Rockset может привязывать ваши таблицы DynamoDB и предоставлять на них полнофункциональный SQL. Вы можете использовать SQL LIKE или REGEXP_LIKE для выполнения элементарного текстового поиска. Но, если вы не выполняете сканирование префиксов, весь инвертированный индекс для поля все равно будет сканироваться. Rockset поддерживает токенизацию текстового поля для эффективного выполнения полнотекстового поиска.
В этом блоге рассказывается о том, как вы можете использовать Rockset для запроса данных в таблицах DynamoDB с использованием SQL: https://rockset.com/blog/running-fast-sql-on-dynamodb-tables/
Кроме того, список функций текстового поиска, поддерживаемых Rockset: https://docs.rockset.com/text-search-functions/
Полное раскрытие: я работаю в инженерной команде @ Rockset.
3 ответа
Еще одна вещь, которая Важными могут быть включенные опции SET . Некоторые из этих параметров достаточно меняют план запроса, чтобы изменить профиль. Некоторые из них могут оказать огромное влияние, если вы посмотрите (например) на вычисленный + сохраненный (и, возможно, проиндексированный) столбец: если параметры SET несовместимы, можно принудительно пересчитать значения, а не использование индексированного значения - которое может изменить поиск индекса в таблице сканирования + вычисления.
Попробуйте использовать профилировщик, чтобы увидеть, какие опции SET «в игре», и посмотрите, если используете эти параметры меняют ситуацию.
Другое влияние - строка подключения;
У нас была похожая проблема, когда запрос выполнялся через 2 секунды в SSMS и занимал более 90 секунд при вызове из клиента .NET (мы написали несколько приложений / сайтов VB / C # для протестируйте его.)
Мы подозревали, что план запроса будет другим, и переписали запрос с явными подсказками зацикливания («соединение внутреннего цикла» и «с индексом»). Это решило проблему.
This is almost certainly due to an 'incorrect' cached query plan. This has come up on SO quite a few times.
Do you have up-to-date statistics? A regular scheduled index maintenance plan?
You can test if it is definitely due to the cached query plan by adding this to your stored procedure definition:
CREATE PROCEDURE usp_MyProcedure WITH RECOMPILE...
This will re-index an entire database (caution if database is very large!):
exec sp_msforeachtable "dbcc dbreindex('?')"
SO posts:
Big difference in execution time of stored proc between Managment Studio and TableAdapter.
Parameter Sniffing (or Spoofing) in SQL Server