Denis Trunin's Blogs: Blocking in D365FO(and why you shouldn't always follow MS recommendations)

[Raven Melancholic]

Цитата:

Сообщение от fed

Насколько я понимаю, при указании firstonly еще и AOS занимается оптимизацией всяких своих внутренних буферов и сетевых обменов, поскольку он знает что второй записи не будет.

Вполне возможно, я не в курсе что происходит внутри Аксапты, смотрел со стороны SQL.
Но в данном случае таблица с кэшированием (предположм, что записи в кэше нет), запрос по первичному индексу (ну или для DAX2012 даже если бы просто по уникальному).
Тут Аксапта явно готовилась, анализировала работу с кэшем, и озаботилась тем как его готовить. Логично предположить, что в таком случае и все свои внутренние структуры она подготовила для получения именно одной записи.
Если же, потратив столько сил на анализ кеширования, внутри аксапты для запроса в SQL про это "забыли" и все работает как в остальных случаях, то я разочарован. Так и в Деда Мороза верить перестанешь.

[Vadik]

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

При FIRSTFAST ядро делает

SELECT TOP 1 (TOP 10 / TOP 100 / TOP 1000)

Дальше уже оптимизатор SQL Server-а думает что здесь можно оптимизировать и как. При singletone lookup по первичному ключу - особенно не наоптимизируешь, заранее известно что вернется либо одна запись либо ни одной, с методом доступа в общем тоже все понятно

https://tinyurl.com/yb7her2j

[Raven Melancholic]

Цитата:

Сообщение от Vadik

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

При FIRSTFAST ядро делает ...

Так не я про особую обработку TOP1 говорил.
Только, наверное, имеется ввиду не FIRSTFAST, а FIRSTONLY...