Советы

Сообщение **Kogep** » 30 дек 2021, 18:38

1. При выполнении кода из двух сессий

BEGIN TRAN
SELECT ... from Table  -- вот здесь зависнет вторая сессия пока не произойдет COMMIT в первой сессии
...
INSERT INTO Table       -- вот тут блочится таблица и др. сессии будут ждать COMMIT'а в SELECT'е

COMMIT

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

2. Избегать использовать LIKE
При использовании = в WHERE и JOIN оптимизатор понимает, что сначала нужно отфильтровать записи, а затем уже джойнить.
При использовании LIKE в WHERE (даже без использования шаблонов) и jOIN оптимизатор нихрена не понимает. Он сначала делает джойн, а затем фильтрует. При джойне больших таблиц это не очень хорошо.

3. Проблема с TOP.
Даже если запрос:
SELECT * FROM TABLE ORDER BY Field

работает быстро, то на больших объемах данных
SELECT TOP 1 * FROM TABLE ORDER BY Field

может работать медленно.

Зависит это от поля, по которому идет сортировка. На скорости точно не скажется, если сортировка будет по кластеризованному ключу, но и по некоторым некластризованнным у меня работало быстро. Очень сильное замедление, в частности, замечено при сортировке по полю datetime (но с datetime вообще индексы работают плохо).

Выход:
1. Либо делать кластeризованный ключ по datetime
2. Можно попробовать заменить на запрос с оконной ф-цией:
SELECT * FROM
(SELECT *, ROW_NUMBER() OVER(ORDER BY Field) as rn FROM TABLE) as t
WHERE rn <= @top