Переодически подвисает Фин Книга Операций

[rmv]

Цитата:

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

Если только нет друго ключа начинающенгося с полей прописанных в коде.

P.S. То что не влезло в одну строчку кода - не резон, так как всегда можно перейти на вторую.

Ну на самом деле SQL серверу все равно какой ключ прописан в коде, поля ключа подставляются в Order By запроса, а вот какой индекс выберит SQL сервер - зависит от статистики на наверно чуть от random'a .
Обратите внимание - проблемы появились после коррекции себестоимости. Мои предположения - на основе статистики накопленной ДО коррекции себестоимости сервер выбирает неоптимальный индекс или сваливается в full scan таблицы. Проверить просто - забэкапить - развернуть - сравнить

[Fordewind]

а вот тут возникла ошибка форума....

[Fordewind]

Цитата:

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

Ну на самом деле SQL серверу все равно какой ключ прописан в коде, поля ключа подставляются в Order By запроса, а вот какой индекс выберит SQL сервер - зависит от статистики на наверно чуть от random'a .
Обратите внимание - проблемы появились после коррекции себестоимости. Мои предположения - на основе статистики накопленной ДО коррекции себестоимости сервер выбирает неоптимальный индекс или сваливается в full scan таблицы. Проверить просто - забэкапить - развернуть - сравнить

чОрт! Адская ошибка форума сожрала мой длинный пост.
Короче: Попадает ли в данном случае поле Postind Date в Order By? Если не попадает то при SETRANGE по этому полю, по идее, SQL будет тормозить?

[rmv]

Цитата:

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

чОрт! Адская ошибка форума сожрала мой длинный пост.
Короче: Попадает ли в данном случае поле Postind Date в Order By? Если не попадает то при SETRANGE по этому полю, по идее, SQL будет тормозить?

В таком случае Posting Date попадает в where условие запроса. Не думаю что оптимизатор настолько глуп чтобы анализировать только order by

[RedFox]

Цитата:

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

Ну на самом деле SQL серверу все равно какой ключ прописан в коде, поля ключа подставляются в Order By запроса, а вот какой индекс выберит SQL сервер - зависит от статистики на наверно чуть от random'a .
Обратите внимание - проблемы появились после коррекции себестоимости. Мои предположения - на основе статистики накопленной ДО коррекции себестоимости сервер выбирает неоптимальный индекс или сваливается в full scan таблицы. Проверить просто - забэкапить - развернуть - сравнить

Перестрой ключи на таблице (когда пользователей не будет)