|
anatoleech_djХомяГanatoleech
Должно быть "Применено-к, применено-из". Используется "Применено-из".
Терминологию осваивать нет резона, да и некогда. При работе с sqlной базой NAV, с SQL
Раз должно быть - делайте каким то образом (каким не знаю и вряд ли это поддерживается, хотя всё возможно) при формировании выборки хинт по "нужному" индексу в Nav
Собственно, это и делает оператор SETCURRENTKEY - указывает ключ для сортировки и фильтрации.
В SQL должен использоваться аналогичный ключ, создаваемый NAV в SQL при установке галки "Maintain SQL index" в списке ключей таблицы. Я так понимаю, что передаваемый SELECT, содержащий ORDER BY, соответствующий выбранному ключу, как раз-таки должен побудить SQL использовать этот ключ (поправьте, если это не так и ORDER BY выполняет функцию, отличную от выбора ключа).Мда... С такой терминологией соваться на форум по MS SQL, пожалуй, действительно не стоит... :)
И пытаться решать подобные проблемы без специалиста, который разбирается в MS SQL, в общем-то, сродни хождению по краю пропасти.
Попытаюсь помочь, чем смогу. Прежде всего, "ключ" в терминологии MS SQL - это не совсем то (а точнее, совсем не то) понятие, которым пытаетесь оперировать Вы. Ключи в MS SQL бывают двух видов - первичный (Primary key) и вторичный (Foregn key). Первичный ключ позволяет однозначно идентифицировать запись в конкретной таблице. Создание первичного ключа сопровождается созданием уникального индекса к данной таблице. Вторичный ключ - это ссылка на запись первичного ключа, то есть на конкретную запись таблицы. Совокупности Primary key - Foregn key создаются для взаимной логической связки нескольких таблиц по некоторым полям. При создании таких связок можно дать указание MS SQL Server обеспечить логическую целостность информации с помощью DRI (Declarative Referential Integrity). То есть, встроенного в MS SQL функционала по обеспечению ссылочной целостности. При попытке удаления записи из таблицы, на которую ссылаются другие таблицы, DRI позволяет выполнить одно из следующих действий:
а) Отказаться удалять запись, если в какой-то другой таблице имеются записи, ссылающиеся на удаляемую (сгенерив ошибку)
б) Вместе с удаляемой записью из данной таблицы удалить также записи из смежных таблиц, которые ссылаются на удаляемую и благополучно завершить операцию
в) Удалить запись из данной таблицы, не проверяя, имеются ли на нее ссылки из других таблиц
В процессе использования таблиц этот функционал "просто работает", никаких дополнительных указаний SQL-серверу по тому, как им следует пользоваться, как правило, в SQL-запросах не содержится.
Теперь два слова об "индексах". В Fox, DBase, Clipper и т.п. РСУБД на заре их зарождения не имелось функционала работы с SQL-запросами. Они содержали свой собственный синтаксис и свои собственные правила обработки данных. В их структуре также создавались "индексы" и так же имелись "данные", но обработка данных производилась с явным указанием, какие индексы следует использовать при выборке данных. То есть, там изначально выдавалась команды:
1. Воспользоваться таким-то заранее созданным индесом (вспомогательной структурой ссылок на таблицу исходных данныхз)
2. Выбрать записи из таблицы данных, "глядя на них" как бы через индекс, на записи которого наложено определенное условие фильтрации.
3. Вернуть результат, который можно обработать по одной записи
Сдается мне, что Вы ожидаете чего-то подобного от MS SQL Server. Но он работает совершенно иначе. "Индекс" для него - это структура, как правило, для его "внутреннего" использования. Какими индексами и в каких случаях пользоваться, он принимает решение САМ , исходя из имеющихся индексов, заранее созданных по полям тех или иных таблиц и исходя из накопленных "статистик" (то есть данных о селективности) каждого индекса. В 99.99% случаев SQL-серверу не требуется давать никаких указаний по поводу того, какими индексами он должен пользоваться, потому что оптимизатор запросов у MS SQL Server в достаточной степени интеллектуален, чтобы выбрать наиболее оптимальный (быстрый) способ выполнения SQL-запроса. В тех же исключительных случаях, когда SQL-серверу даются конкретные указания по использованию индесов (созданных заранее), то обычно это делают специалисты в области MS SQL Server достаточно высокого уровня, которые очень хорошо разбираются в том, как работает оптимизатор запросов MS SQL, и четко отдают себе отчет, почему их не устраивает логика работы его "встроенного интеллекта". Чаще всего это происходит тогда, когда в некоторых таблицах происходит очень частое добавление и удаление больших объемов информации, при которых картина селективности различных индексов по этой таблице радикально изменяется. А процедура обновления статистик индекса не может использоваться слишком часто, потому что она замедляет работу SQL-сервера. То есть, опитимизатор запросов может сформировать неоптимальный план выполнения запроса потому, что пользуется устаревшими статистиками, который с высокой долей вероятности в существенной степени не соответствуют текущему состоянию индесов. Вот в этих случах в SQL-запрос добавляются так называемые "хинты" - подсказки оптимизатору запросов о том, какими индексами он должен пользоваться. Опять же "какими индесами" в терминах MS SQL Server, то есть, должно быть указано имя ранее созданного индеса, и для того, чтобы на него сослаться, это имя требуется знать .
Теперь собственно о тексте SQL-запроса. Прежде всего, хочу заметить, что стандартный SQL-запрос (не использующий специфику синтаксиса того или иного SQL-сервера) - это изначально именно язык ЗАПРОСОВ , а не "инструкций". То есть, SQL-запрос сообщает серверу лишь о том, какой РЕЗУЛЬТАТ намерен получить тот, кто этот запрос отправил. А вот способ (алгоритм), которым этот результат будет получен, SQL-сервер выбирает САМ . Теперь попытаемся перевести на русский язык, какой запрос пытается отправить NAV на MS SQL Server:
авторSELECT * FROM "Основная БД для тестирования$Товар Книга Применения"...
Выбрать все колонки из таблицы "Основная БД для тестирования$Товар Книга Применения"...
автор...WITH (READUNCOMMITTED)...это единственный хинт, который имеется в данном SQL-запросе. Он сообщает SQL-серверу, что ему разрешается читать так же те записи, которые добавились или изменились другими пользователями в других транзакциях, даже если эти транзакции не завершены и могут быть откачены.
автор...WHERE (("Примен.-к Операции Но."<>0)) AND (("Примен.-из Операции Но."=30195))...В указанной ранее таблице необходимо выбрать не все записи, а только те, для которых значение поля "Примен.-к Операции Но."<>0 и значение поля "Примен.-из Операции Но."=30195. Обратите внимание, здесь нет никаких указаний по поводу "индексов" или "ключей", здесь речь идет просто о ПОЛЯХ таблицы. Если по этим полям ранее не было создано никаких индесов, то оптимизатор SQL-сервера может попытаться выбрать записи методом полного просмотра всех записей этой таблицы. Если индексы были созданы, то он ими, скорее всего, воспользуется, если определит, что они обладают достаточной селективностью.
Обращаю также внимание на то, что порядок следования логических условий в SQL-запросе, объединяемых логическим AND, значения НЕ ИМЕЕТ . Оптимизатор запросов, если обнаружит ранее созданный индес по полю "Примен.-из Операции Но.", сам определит, что им нужно воспользоваться в первую очередь, а уже потом допольнительно отфильтровать из полученного набора записи в соответствии с условием "Примен.-к Операции Но."<>0
автор...ORDER BY "Примен.-к Операции Но.","Примен.-из Операции Но.","Операция Но."Полученный набор записей должен быть отсортирован по полю "Примен.-к Операции Но.". Для тех записей, у которых значения этого поля одинаковы, они сортируются в пределах одного значения по полю "Примен.-из Операции Но.". Для тех записей, у которых одинаково значение двух полей "Примен.-к Операции Но." и "Примен.-из Операции Но.", отсортировать по полю "Операция Но.".
Инструкция "ORDER BY" предписывает отсортировать записи в определенной последовательности. Если имеется индекс, по соответствующим полям, SQL-сервер им воспользуется, если нет, то отсортирует без индекса. Если количество возвращаемых записей до 200-300, то операция сортировки записей врядли сильно скажется на времени выполнения запроса. Если же их многие тысячи или сотни тысяч, тогда нужно будет убедиться, что индексы по соответствующим полям созданы и что статистики по ним регулярно обновляются.
Вот, собственно, и всё, что сказано в тексте SQL-запроса. "Верни мне записи, отфильтровав их по такому-то условию и отсортировав их таким-то образом". Ни слова ни о каких "ключах" и "индексах".
Теперь по сути. Самый простой способ без проникновения в расшифровки плана выполнения запроса и без "прослушивания" SQL-сервера утилитой Profiler (требуется некоторая сноровка, чтобы научиться отфильтровывать нужную информацию среди того водопада запросов, которые поступают на SQL-сервер).
Попробуй выполнить это запрос из Query Analyzer. Если он отрабатывает медленно, значит проблема на стороне MS SQL Server. Она может быть связана с тем, что по полю "Примен.-из Операции Но." индекс не был создан. Либо с тем, что индекс создан, но статистики по нему 10 лет не обновлялись.
Если запрос отрабатывает моментально, значит MS SQL Server "ни в чем не виноват".
Попробуй сначала выполнить запрос к MS SQL Server в Query Analyzer, сообщи о результатах, потом расскажу, что делать дальше.
|
