Здравствуйте, LuciferArh, Вы писали:

FLY>>Да брось, кол-во таких записей ничтожно для того чтобы их учитывать (я сейчас о времени говорю, а не о целостности данных). Ну сколько 360 человек, даже если одновременно ломанутся добавлять, смогут создать записей?
LA>Дело не в том, сколько они создадут записей. Дело в качестве этих записей, когда у клиентов появятся совершенно левые цифры, ломающие все.
А изначально говорил о скорости

Здравствуйте, rFLY, Вы писали:

FLY>А изначально говорил о скорости

Вот как ты думаешь, если мне NOLOCK вернет десяток-другой тысяч совершенно левых записей, скорость возрастет? Ты проверь как-нибудь на нагруженной системе и потом нам расскажешь.

Здравствуйте, LuciferArh, Вы писали:

LA>Вот как ты думаешь, если мне NOLOCK вернет десяток-другой тысяч совершенно левых записей, скорость возрастет? Ты проверь как-нибудь на нагруженной системе и потом нам расскажешь.
Ну во-первых, ты сказал что записей 5000, откуда десяток-другой? Да и десяток другой залоченных на изменение записей возможен только при скрипте их апдейтящих или при сравнимом (десяток-другой) количестве пользователей, но у тебя их 360 максимум, если ты не ошибся в изначальном сообщении:

Примерное количество клиентов онлайн, по которым надо отрабатывать, — 350-360 (зависит от активности). Обрабатываются четыре таблицы, примерно пять тысяч строк(!!!).

Здравствуйте, Somescout, Вы писали:

S>Когда пытался понять что такое CROSS APPLY наткнулся на такую статью. Возможно поможет, хотя тут инвертированное условие.
Спасибо за кросс эпли, как-то мимо меня прошло

Здравствуйте, Didi, Вы писали:

D>Народ, есть ли способы помочь серверу выполнить запрос:
D>SELECT * FROM Table WHERE field1 <= const AND const <= field2
D>field1, field2 — поля таблицы типа INT
D>field1 <= field2 или это всегда перебор всех записей в таблице?

SELECT * 
FROM Table 
WHERE field1 <= :const 
  AND field2 >= :const
;

Создать индекс по field1, уже будет позиционирование по индексу и потом его сканирование.

Если это начало и конец диапазонов, можно переписать запрос немного

SELECT * 
FROM Table 
WHERE field1 <= :const 
  AND field2 = ( select min(field1) from Table where field1 > :const ) - 1
  --and field2 >= :const
;

и создать другой индекс -- (field1, field2)

Здравствуйте, MasterZiv, Вы писали:

MZ>

MZ>SELECT * 
MZ>FROM Table 
MZ>WHERE field1 <= :const 
MZ>  AND field2 >= :const
MZ>;
MZ>

MZ>Создать индекс по field1, уже будет позиционирование по индексу и потом его сканирование.

А теперь представьте что первая :const > max(field1) и тогда сканировать придётся все записи индекса. В чём и состоит проблема.

Здравствуйте, Somescout, Вы писали:

S>Здравствуйте, MasterZiv, Вы писали:

MZ>>

MZ>>SELECT * 
MZ>>FROM Table 
MZ>>WHERE field1 <= :const 
MZ>>  AND field2 >= :const
MZ>>;
MZ>>

MZ>>Создать индекс по field1, уже будет позиционирование по индексу и потом его сканирование.

S>А теперь представьте что первая :const > max(field1) и тогда сканировать придётся все записи индекса. В чём и состоит проблема.


не понял. я наврал где-то в преолбразовании запроса ?
МОг, писал ночью от бессонницы.

Здравствуйте, Didi, Вы писали:

D> Народ, есть ли способы помочь серверу выполнить запрос:
D> SELECT * FROM Table WHERE field1 <= const AND const <= field2
D> field1, field2 — поля таблицы типа INT
D> field1 <= field2 или это всегда перебор всех записей в таблице?

Есть.

1. Создать индексы. Какой набор индексов будет наиболее эффективным, зависит от данных и наиболее частых значений const, это нужно проанализировать и, возможно, промоделировать. Вероятные варианты, навскидку:

а) (field1, field2), (field2)
б) (field2, field1), (field1)
а) (field1, field2), (field2, field1)

2. Условие field1 <= field2 прописать в check constraint.
3. Собрать и актуализировать периодически статистику.
4. Если этого окажется недостаточно, можно передавать в запрос значение const не параметром, а подстановкой. Тогда оптимизатор будет каждый раз строить план выполнения, исходя из конкретного значения const, а не использовать построенный ранее.

Здравствуйте, Didi, Вы писали:

D>Народ, есть ли способы помочь серверу выполнить запрос:
D>SELECT * FROM Table WHERE field1 <= const AND const <= field2
D>field1, field2 — поля таблицы типа INT
D>field1 <= field2 или это всегда перебор всех записей в таблице?

Давай пойдем с другой стороны — какие проблемы выполнить такой запрос.
1) параметр попадает в начало диапазона, в худшем случае const < min(field1) — поможет индекс (field1, field2)
2) параметр попадает в конец диапазона, в худшем случае const>max(field2) — поможет индекс (field2 desc, field1 desc)
3) так как в зависимости от параметра должны быть разные планы, то попадаем на parameter sniffing problem, нужно добавить OPTION(RECOMPILE) к запросу
4) чтобы правильно выбирался план надо обновлять статистику, по-умолчанию для построения статиcтики используется 10000 строк, если строк в таблице сильно больше, то нужно автообновлние отключить и руками прогонять UPDATE STATISTICS WITH FULLSCAN по ночам
5) Ну и конечно убрать select * в запросе и укаать нужную проекцию.
6) Если таблица большая и запросы часто приходят в середину диапазона, то воспользоваться Relational Interval Tree — http://blogs.solidq.com/en/sqlserver/static-relational-interval-tree/

Здравствуйте, wildwind, Вы писали:


W>4. Если этого окажется недостаточно, можно передавать в запрос значение const не параметром, а подстановкой. Тогда оптимизатор будет каждый раз строить план выполнения, исходя из конкретного значения const, а не использовать построенный ранее.

Вовсе не обязательно. Вообще это независимые вещи, есть или нет параметр и есть или нет кэширование плана.