Прикладываю видеофакт, где был задан этот вопрос на инфостарте
https://youtu.be/8gH3Prmz05w
---
ditp, По ряду формальных признаков можно судить об НЕОПТИМАЛЬНОСТИ. А вот об оптимальности - гораздо сложнее.
---
Gilev.Vyacheslav, в теории то можно, особенно когда в тексте запроса присутствуют разыменованные поля боле чем через одну точку, обращения "через точку" к реквизитам полей составных типов и т.п. явные "грубые" ошибки.
Правда стоит учитывать, что эти самые "грубые" ошибки, в определенных случаях, могут быть и не ошибками вовсе, а осознано принятым проектным решением.

Насчет инструментов - не уверен. Если отвечать не думая - то да, есть ряд инструментов - начиная от штатных средств серверов СУБД и заканчивая спец. инструментарием заточенным на решение подобных задач, таких как консоль запросов из инструментов разработчика, консоль запросов из новых версий БСП или консоль от вашей команды.

Вот только "за кадром" остаётся тот факт, что при оценке оптимальности запроса все инструменты используют данные сервера СУБД в которых важным объектом анализа является не только текст запроса, но и куча дополнительных данных, таких как накопленная статистика, количество записей в таблицах, существующие индексы и т.п.
---
Сказать можно.
При наличии информации о структуре метаданных.
---
По тексту запроса нельзя почти никогда нельзя ничего сказать об его оптимальности.
По плану запроса в ряде случаев можно предположить оптимальность.
По плану запроса и статистике используемых таблиц регулярно можно предположить от оптимальности.
Зная план запроса, статистику и логические связи используемых таблиц обычно можно выдвинуть предположение об оптимальности.
Но что такое оптимальность? Это когда лучше уже нельзя написать? Так самый дубовый запрос может быть оптимальным, потому что в текущей базе лучше требуемые данные просто нельзя выбрать.
---
Думаю в данной постановке вопроса - нельзя. Если будет возможность провести "испытания" запроса на конкретной базе, то скорее всего запрос можно будет сделать оптимальным. Так же согласен - очень важно понимать что такое определение оптимальности.
---
Если вопрос понимать, существует ли алгоритм, который только по тексту запроса может сделать его максимально оптимальным. То да, ответ не существует.
Но, существуют многочисленные ошибки, которые могут быть распознаны и определены независимо от структуры метаданных в данный конфигурации. таким образом ответ на данный вопрос звучал бы примерно так:
"Да, возможно в пределах общих правил построения запроса, не учитывая структуру метаданных. Знание структуры метаданных, вероятно, позволит оптимизировать запрос в еще большей степени". Точно так же работает синтаксисический и семантический контроль в средах разработки. Очевидные нарушения правил могут быть распознаны.
---
Артано, Если вопрос понимать, существует ли алгоритм, который только по тексту запроса может сделать его максимально оптимальным. То да, ответ не существует.

А вот SQL Server почему-то понимает...
---
DenisCh, И что он понимает?
По тексту запроса SQL-сервером строится план запроса. С учетом информации, не имеющейся в тексте запроса. Индексы, размеры таблиц, статистика использования.
Фактически, строится новый, уточнённый запрос, учитывающий тонкости, которые не детализированы в изначальном тексте запроса. В разных ситуациях для одного и того же текста запроса может получиться разный план запроса. Это уже само по себе показывает, что из изначального текста запроса не всегда можно что-либо сказать об оптимальности. Тупо не хватает данных для анализа.
А вот если бы вопрос был поставлен как "можно ли запустить в конкретной 1С базе обработку, которая бы по тексту запроса определила оптимальность его исполнения в ЭТОЙ базе", тогда ответом, скорее всего, было бы ДА.

Формальные критерии известны давно. Возьми и выполни свой запрос в своей базе с получением плана запроса. Видишь TABLE SCAN на таблице бОльшей, чем несколько десятков записей? Плохо. Видишь INDEX SCAN? Подумай еще раз над запросом, вряд ли он оптимален. При небольшом количестве записей в результате запроса видишь заметно большее количество логических чтений какой-нибудь таблицы? Возможно это неизбежно, но задумайся над логическими связями таблиц.

Но даже соединение всех подобных формальных критериев в одном плане запроса не говорит о том, что он не оптимален. Да, плохой запрос. Да, тяжёлый. Но возможно ли выбрать требуемые данные лучше в текущей структуре данных?
---
Думаю, что можно сказать об оптимальности какого-либо запроса, относительно других подобных запросов. Всё в нашем мире относительно!
---
В какой-то мере судить по тексту можно, в книгах и на ИТС есть даже правила, как не надо писать запросы. Но детально сказать нельзя, т.к. зависит не только от текста запроса, но и от СУБД и от данных.
---
Нельзя, только текста запроса мало.
---
теоретически возможно, но с кучей оговорок которые сведутся к изучению структуры данных в запросе
---
А как вы собрались говорить об оптимальности запроса, не зная для чего он нужен? Какие данные должны получиться в результате выполнения запроса? Конечно, можно говорить о логичности, о соответствии определенным принципам и правилам построения запросов. Можно даже сказать о том что мы получим в результате выполнения запроса. Но.. Насколько то что получится в результате выполнения соответствует тому, что необходимо получить? Просто глядя в текст мы можем говорить лишь о правильности или неправильности его составления, но вот об оптимальности речи и быть не может.
---
Однозначно нельзя
---
Можно ли по наличию бычков на полу и водочных бутылок на подоконнике однозначно определить, что в роте бардак?
Конечно же, нет. Возможно, это было осознанно принятое проектное решение командира части.
Но в 99.99% случаев да.
---
Вот. По моему, это плохой, неоптимальный запрос:

```1c
    ВЫБРАТЬ
    Док.ВидОплаты.ТипОплаты КАК ТипОплаты,
    Док.ВидОплаты КАК ВидОплаты,
    СУММА(ВЫБОР
    КОГДА Док.Ссылка.ВидОперации = &ВидОперацииПродажа
    ТОГДА Док.Сумма
    ИНАЧЕ -1 * Док.Сумма
    КОНЕЦ) КАК Сумма,
    Док.ПроцентТорговойУступки,
    СУММА(ВЫБОР
    КОГДА Док.Ссылка.ВидОперации = &ВидОперацииПродажа
    ТОГДА Док.СуммаТорговойУступки
    ИНАЧЕ -1 * Док.СуммаТорговойУступки
    КОНЕЦ) КАК СуммаТорговойУступки
    ИЗ
    Документ.ЧекККМ.Оплата КАК Док
    ГДЕ
    Док.Ссылка.КассаККМ = &КассаККМ
    И Док.Ссылка.Проведен
    И НЕ Док.Ссылка.СтатусЧекаККМ = ЗНАЧЕНИЕ(Перечисление.СтатусыЧековККМ.Архивный)
    И НЕ Док.Ссылка.СтатусЧекаККМ = ЗНАЧЕНИЕ(Перечисление.СтатусыЧековККМ.Аннулированный)
    И НЕ Док.Ссылка.СтатусЧекаККМ = ЗНАЧЕНИЕ(Перечисление.СтатусыЧековККМ.Отложенный)
    И Док.ВидОплаты.ТипОплаты <> &ТипОплатыНаличные

    СГРУППИРОВАТЬ ПО
    Док.Ссылка,
    Док.НомерСтроки,
    Док.ВидОплаты.ТипОплаты,
    Док.ПроцентТорговойУступки,
    Док.ВидОплаты
```

Как ни старался, аргументов, что этот запрос хорош, я не нашел.
Так что, да, в ряде случаев возможно по тексту запроса сказать об его оптимальности.
---
ditp, По ряду формальных признаков можно судить об НЕОПТИМАЛЬНОСТИ. А вот об оптимальности - гораздо сложнее.
(15) ipoloskov, Наличие "бычков на полу и водочных бутылок на подоконнике" показывает, что в роте бардак. А отсутствие их не показатель, что бардака нет.
С запросом тоже самое. Есть формальные признаки плохого запроса. Но нет формальных признаков хорошего.
---
vcv, отдал Вам "призовые" на наглядно показанную сущность )
---
Думаю, что в общем случае - нельзя. Более того, в идеале - текст запроса и не должен влиять на оптимальность его выполнения.
SQL по задумке - всего лишь язык описания требуемого результата, а не способа его достижения.
И чем лучше реализован оптимизатор запросов - тем меньше запутанность и неоптимальность описания результата должна влиять на оптимальность его достижения. Идеальный оптимизатор ДЛЯ ЛЮБОГО описания одной и той же выборки данных должен выдавать один и тот же максимально оптимальный план ее получения.
К сожалению, на практике все не так радужно. И зная особенности работы оптимизатора в конкретной версии конкретной СУБД плюс большой опыт анализа планов фактического выполнения, часто можно строить обоснованные предположения об эффективности запроса, выраженного одним либо другим способом. Но это знание непостоянно и все равно имеет вероятностный характер.
---
даже по заголовку http://buh.ru/forum/forum18375/topic89295/
---
Можно, есть стандартные правила формирования оптимального запроса, также можно использовать SQL profiler для выявления узких мест оценки времени выполнения как кусков так и целого запроса.
---
1. Только по тексту - нельзя.
2. С учетом метаданных - в теории
3. С Учетом метаданных и селективности данных - уже можно относительно к виду БД.

Пример:
Регистр остатков. (РО)
 Измерения( для примера)
 Склад - ссылка - индексируемое
 Ном - ссылка - индексируемое
 ДокРез - ссылка - индексируемое
 Ресурс - Количество - Целое

Наполнение данных:
Склад - Сотни элементов
Ном - сотни тысяч,
ДокРез - документ резерва - может быть не заполненным (допустим для 60%)пустая ссылка
в одном регистраторе десятки - сотни строк
регистраторов за месяц - десятки тыс.

Самый простой запрос выбора остатков на дату:

```1c
    ВЫБРАТЬ
    РО.Склад
    РО.Ном,
    РО.ДокРез КАК СчетУчета,
    РО.Количество
    ИЗ
    РегистрНакопления.РО.Остатки(&Граница, Склад = &Склад И Ном В (&СписокНом) И ДокРез = &ДокРез) КАК РО
```
На файловой версии все будет ок, на sql - периодические внезапные провалы производительности -
такой простой запрос будет выполнятся иногда быстро (после сброса процедурного кеша), иногда долго - план выполнения у него почти всегда будет одинаковый.. в выборке из текущих движений будет использовать индекс по ДокРез - и по этому плану (с точки зрения зрения SQL самому оптимальному) если &ДокРез = ПустаяСсылка будет выбираться миллионы движений (делаться миллионы чтений) и только потом отбор по предикатам Склад, Ном.
Разница во времени выполнения с заполненным ДокРез - в сотни и тысячи раз.

А при 100% заполнении ДокРез - это будет самый оптимальный план - и самое лучшее время выполнения.

Так что селективность отборов можно оценить только по данным.
---
Ребята, оптимальность, как и свежесть, не может быть второй, меньшей, большей, максимальной и т.д. Оптимум и есть максимально большое и т.д. Все остальное не оптимум. А большая/меньшая/максимальная и т.д. оптимальность - тавтология.
---
sssss_aaaaa_2011, Говорите "оптимальность, как и свежесть, не может быть второй, меньшей, большей, максимальной и т.д"
Ну, вот вам байка в тему:
---
ну да, пример такого оптимума я привел выше)) это из личного опыта.
при заполненном ДокРез - проводилось 10 документов в секунду.. при незаполненном - 1 документ за 10 секунд - вот такой может быть опасный оптимум.. тем более что не мы его сами определяем, а считает его SQL.
---
конечно видео было не просто так
многие заблуждаются просто потому что "не в курсе" )

мы такую работу проделали и наш алгоритм в том числе вычисляет неоптимальности на основе текста и разумеется метаданных https://youtu.be/q9bKv5LwRdk?t=7m4s , но и конечно и по плану запроса второй алгоритм тоже есть

готовы всем желающим предоставить возможность в этом убедиться
информация как "пощупать" новую технологию расположена на главной странице http://www.gilev.ru/#ConsoleGilevRu в секции "Разработчику: Быстрый анализ ошибок в запросе"
---
Gilev.Vyacheslav, мы такую работу проделали и наш алгоритм в том числе вычисляет неоптимальности на основе текста и разумеется метаданных, но и конечно и по плану запроса второй алгоритм тоже есть
Тогда бы не сбивали общественность с толку громкими заголовками.
"на основе текста и разумеется метаданных" плюс "конечно и по плану запроса" никак не эквивалентно "по тексту запроса".
"вычисляет неоптимальности" заметно отличается от "сказать об его оптимальности".

Легко, знаете ли, доказать, что существует хромая белая обезьяна. А вот вы попробуйте доказать, что её не существует.
Задача поиска неоптимальностей (тут уже несколько раз сказали, что для этого существуют формальные критерии) сильно отличается от задачи доказательства оптимальности.
---
vcv, люди не такие и глупые, прочтут эту и ветку и смогут сами разобраться
главное что теперь информации достаточно

"вычисляет неоптимальности" заметно отличается от "сказать об его оптимальности"
мое сугубо личное мнение что в большинстве случаев в практической части понимание неоптимальности позволяет добиться требуемой оптимальности
---
Gilev.Vyacheslav, люди не такие и глупые, прочтут эту и ветку и смогут сами разобраться
главное что теперь информации достаточно
Лучше всё же не вводить людей в заблуждение маркетинговыми лозунгами (ваш заголовок я воспринимаю только так).
Надеяться, что все смогут разобраться и сделать правильные выводы, это примерно как надеяться, что люди начнут писать правильным языком только потому, что браузер подчеркивает слова с ошибками.
мое сугубо личное мнение что в большинстве случаев в практической части понимание неоптимальности позволяет добиться требуемой оптимальности
Угу, угу. Восприятие вашего лозунга в заголовке с приемлемой точностью позволяет добиться приемлемой оптимальности запроса. А рассмотрение всех предупреждений компилятора и использование статистического анализатора кода позволяет добиться оптимальной программы. Ну просто однозначно! /сарказм/

Я ничуть не умаляю достоинств ваших инструментов, они нужны, полезны и во многих случаях просто mast have. Но эта ветка получилась не про ваш инструмент, а абстрактно-теоретическую проблему: "Возможно ли по тексту запроса сказать об его оптимальности". И большая часть мнений, на сколько я вижу, сошлась на том, что по тексту запроса - нельзя. Это ответ на ЗАДАННЫЙ вами в (1) вопрос.
---
vcv, на скриншоте чего больше видите - маркетинга или информацию как можно оптимизировать запрос? (движок слегка уменьшает масштаб, можно скачать картинку чтобы увидеть в оригинальном размере)
---
Gilev.Vyacheslav, Вы упорно не замечаете, что в заголовке темы задан один вопрос, а вы говорите про другой.
Вот смотрите, текст запроса:

```1c
    ВЫБРАТЬ
    | Контрагенты.Ссылка
    |ИЗ
    | Справочник.Контрагенты КАК Контрагенты
    |ГДЕ
    | Контрагенты.ИНН = &ИНН
```

В полном согласии с темой "Возможно ли по тексту запроса сказать об его оптимальности" я даю вам только текст запроса. Никакой информации о конфигурации, структуре базы, наличии индексов, размере таблицы.
Скажите, этот запрос оптимален? Ответ, что в нем нет явных ошибок меня не устраивает, вы обещали про оптимальность сказать. :)

Ладно бы я один был такой тролль, буквоед и придирала! Но в этой теме в большинстве постов высказано мнение, что текста запроса мало, нужно иметь информацию о базе, плане запроса и, желательно, назначении запроса.
Вы же подразумеваете, что у вас всё то есть, хотя в исходном вопросе "Возможно ли по тексту запроса сказать об его оптимальности" ничего такого не подразумевается.

Я почему говорю "маркетинг"? Потому что вы подразумеваете ответ "если вы на своей базе запустите наш инструмент и проверите свой запрос..."
А если я аутсорсер? Клиент мне базу не даёт. Доступа к своему серверу не даёт. Я не имею реальной статистики, не имею реальных данных о размерах таблиц. План запроса, соответственно, на своём тестовом сервере получаю плюс-минус валенок. И хорошо еще если клиент не параноик и даёт свою нетленную конфигурацию, а не вольное описание нужных таблиц в стиле "Рабинович напел".
А тут вы, с обещаниями "по тексту запроса..." :)
---
vcv, Вы же подразумеваете, что у вас всё то есть, хотя в исходном вопросе "Возможно ли по тексту запроса сказать об его оптимальности" ничего такого не подразумевается.
 В моем понимании подразумевается ВСЯ информация которая доступна без его исполнения. Если кажется что это другой вопрос, тогда считайте эту формулировку вопроса конечной, я ее доуточнил. Ок?

Конечно запрос не может быть оптимальным для всех одинаково. Разные данные, разное железо, даже статистика - все влияет.

А если я аутсорсер? Клиент мне базу не даёт. Ну значит Вы сможете помочь ему с меньшей эффективностью и часть проблем не увидеть, а только совсем "грубые универсально" ошибки. Но давайте не уходить в обсуждение "уровней оптимальности", а считать максимально достижим из текущих условий.

В целом критику меня считаю конструктивной, спасибо.
---
Не хочу создавать новую тему создавать, можете подсказать есть ли возможность в запросе получить список наименования справочников докуменентов и т.д. в любом виде? Например, результат запроса: Справочник.Сотрудники, Справочник.Клиенты. Вот наподобие такого Справочник.Сотрудники.* только не для реквизитов, а для наименование справочника, вопрос может глупый тока пару дней учу язык запросов. Спасибо заранее.
---
user597384_fedoranigma, все таки создайте отдельную ветку пожалуйста
---
Что-то я задумался, а что такое оптимальный запрос? На программном уровне более менее понятно, а на общечеловеческом? Если на рабочей базе запрос выполняется 30 секунд, а пользователям на это пофиг, то этот запрос оптимален?
---
spe1c, Хороший и уместный вопрос.
Википедия говорит, что
Оптимальное (от лат. optimus — наилучшее) решение — решение, которое по тем или иным признакам предпочтительнее других.
В технике оптимальный (вариант, решение, выбор и т. д.) — наилучший (вариант, решение, выбор, …) среди допустимых при наличии правила предпочтения одного другому. Такое правило называется критерием оптимальности, а мерой предпочтения будут служить показатели качества. Можно говорить об оптимальном варианте только при удовлетворении двух условий:
* наличия хотя бы одного критерия,
* наличия не менее двух сравниваемых вариантов (необходимость осуществления выбора).

Самым распространённым критерием оптимальности запроса служит время исполнения. Хорош критерий количества логических чтений. Неплохо было бы учесть количество и вид возникающих блокировок. И так далее.

В любом случае, при любых критериях оптимальности, неизменно одно - оптимальность, это понятие относительное, а не абсолютное. Можно написать запрос оптимальней другого запроса. Можно написать оптимальный запрос по сравнению со своим средним уровнем писательства. Можно написать оптимальный запрос по сравнению со средним уровнем среднего 1Сника.
Теоретически, можно написать оптимальный запрос по сравнению и неким умозрительным идеалом, который, как известно, недостижим. Впрочем, критерии идеальности, это тема для отдельной диссертации :)
---
подпишусь
---
На практике реального использования консоли прочувствовали потребность у рекомендаций обозначать "степень вероятности". Некоторые рекомендации приемлемы в очень частных случаях. Тем не менее консоль автоматизирует рутинные действия по анализу и позволяет "не забывать" проверить некоторые стандартные шаблонные проверки. Думаю через пару лет такой анализ станет уже привычным стандартом.
---
Я тоже подпишусь - интересно

Лично для себя оптимальность рассматриваю с позиции 2-х параметров скорости выполнения и затраченности ресурсов. Т.е. получение высокой скорости обработки при использовании минимального количества ресурсов системы.
---
https://youtu.be/-bharUXv19M
---
Фокус не удался. Всех тузов в рукаве раскрыли с первых постов.
---
Тузы раскрываются сразу при демонстрации инструмента. просто заголовок провокационный для такого человека как Вячеслав.
---
Просто оценка информированности сообщества,а то некоторые "до сих пор кровопусканием лечат"... :)
---
продолжение http://www.forum.mista.ru/topic.php?id=782635 ...