Ariochили тупо в клиенте сделать цикл по приоритетам, как только нашлась первая запись, цикл прерывать

Да, вариант рабочий, я просто хотел обойтись одним запросом
Ariochи поскольку тебе все равно никогда больше одоной строки не надо, то вместо "ORDER BY tbl1.Priority DESC" написать "WHERE tbl1.Priority = ( SELECT MAX (tbl1.Priority) )"

Это не прокатит, может быть так, что запись с максимальным приоритетом не удовлетворяет другим условиям, например по времени, а записи с меньшим - удовлетворяют. В итоге, при наличии реальных записей система будет стоять.
AriochНо IMHO зря это. Лучше реально считывать пачками хотя бы пару десятков задач, а потом уже на клиенте их разбирать по потокам.

Да уже предлагали этот вариант ( Дегтярев Евгений ) - один поток, обработчик базы, раскидывает данные по потокам. Я предположил что это чересчур сложно, имея сервер БД, который в общем то должен сам решать эту задачу
AriochВпрочем, если обработка задачи по 10 секунд... (интересно, почему так долго)

Пользователь долго думает.
AriochВот это мне тоже не нравится.
Я бы лучше сделал таблицу-очередь и в неё вставлял Приоритет + ID обработчика + ID задачи (ссылку на таблицу/таблицы с задачами).
Соответственно, при ошибке в обработчике можно задачу возвращать в пул "неназначенных".
При Успешной обработке - просто удалять из таблицы.

В общем то примерно так оно сейчас и работает, когда я добавил синтетическое поле приоритета
AriochУ тебя же похоже что во-первых идёт модификация "широкой" таблицы по одному столбцу.
Во вторых получается таблица, где TextMarked=0 выполняется только у очень немногих записей.

50 тыс записей, 10 потоков, т.е. TextMarked=0 у 49990 записей. Очень немного записей (обычно 0) получается когда не выполняется условие, подобное для всех, например время. Тут сразу получается очень долго. Очевидный вариант решения, который приходит в голову, это сделать еще один запрос, выдающий возможные по условию TaskID (это к примеру на предыдущей странице) и только по ним делать выборку:


и затем цикл по всем полученнным TaskId:


Как сделать такой же эффективный один запрос я не знаю.

m7mВстряну в середину разговора
Если уже получил нужные TaskID из Table2 в первом запросе то зачем
JOIN да еще и LEFT во втором
Не знаю что там было раньше написано однако эти два запроса обьеденить в "такой же эффективный один запрос" нет никаких проблем


Пример просто был вырожденный чересчур, реально в Table2 имеются еще полезные поля которые нужно извлечь с помощью JOIN.
Да действительно, заменить LEFT на INNER в голову не приходило, раньше где ни использовал INNER, всегда медленно было, а сейчас протестировал с INNER - мгновенно происходит при невыполнении условия
Дегтярев Евгенийне первый раз говорят - сделайте отдельную узкую таблицу для очереди с необходимым и достаточным набором полей, постройте индексы покрывающие ваши кейсы и крутите ее как угодно, разделите захват таска и получение данных по нему

зы
и даже без индексов, 50т записей в табличке с десятком целых полей - фильтр + сортировка + получение первой записи менее 50мс
так почти все поля и нужны (процентов 70), если все вносить в одну таблицу, то постоянно придется отслеживать все изменения в исходных, коих различных 6 штук, но вариант конечно рабочий

MolochnikДа действительно, заменить LEFT на INNER в голову не приходило, раньше где ни использовал INNER, всегда медленно было, а сейчас протестировал с INNER - мгновенно происходит при невыполнении условия

А нет, все от данных зависит, сейчас тестировал на 200 тыс идентичных записях в обоих серверах. Составил табличку

1)Если нет ни одной удовлетворяющей записи,
FB
INNER JOIN - 1.6 сек
LEFT JOIN - 5.5 сек

MS
INNER JOIN - 0.6 сек,
LEFT JOIN - 0.6 сек

2) Если из 200 тыс доступны по условию все, то при получении одной записи
FB
INNER JOIN - 20 сек,
LEFT JOIN - 0.8 секунды

MS
INNER JOIN - 0.01 сек
LEFT JOIN - 0.01 сек

Последние результаты для FB просто удручающие

AriochMolochnikПоследние результаты для FB просто удручающие
а если перед запуском запроса выключать службы FB и MS SQL, а потoм снoва их включать и запрос прогонять на "холодной" базе (т.е. убрать влияние кэшей) ?
Да сделал так, еще дополнительно провел бэкап рестор базы, результаты получше стали
1)Если нет ни одной удовлетворяющей записи,
FB
INNER JOIN - 1.2 сек
LEFT JOIN - 4.1 сек

2) Если из 200 тыс доступны по условию все, то при получении одной записи
FB
INNER JOIN - 17 сек,
LEFT JOIN - 0.015 сек

То есть в идеальном случае, когда любая запись подходит FB работает почти как MS, что не может не радовать. Но INNER JOIN просто смерть какая-то.

Симонов ДенисMolochnik,

я тебе уже советовал отделять условия фильтрации от остальных данных?

делай так




если этот запрос будет быстро работать, то и остальное заработает.
Потестировал ваш вариант, оставил одно поле
и убрал
иначе выдавал ошибку. Результаты следующие:
1)Если нет ни одной удовлетворяющей записи (Count =0)
FB
INNER JOIN - 1.3 сек
LEFT JOIN - 3.8 сек

MS
INNER JOIN - 0.005 сек,
LEFT JOIN - 0.005 сек

2) Если из 200 тыс доступны по условию все ( Count =200000)
FB
INNER JOIN - 4.2 сек,
LEFT JOIN - 4.2 сек

MS
INNER JOIN - 0.7 сек
LEFT JOIN - 0.7 сек
m7mВот тут ты не прав
нельзя просто так заменить LEFT JOIN на INNER JOIN
ибо это совершенно разные запросы и
совершенно разные результаты выполнения

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

m7mне видя ни структур таблиц, ни планов, ни запросов
мы тебе тут много чего насоветуем

ззы. то что я написал относилось конкретно к тем двум запросам что были в сообщении
и никак не означало что надо заменить LEFT JOIN на INNER JOIN в твоем исходном запросе
Реально там нет ничего интересного, ну вообще ничего, 6 таблиц джойнятся с разными несложными разумными условиями, никаких нестед таблиц или сложных конструкций, две таблицы большие да, по 200 тыс записей, джойнятся один к одному по полю, которое в одной таблице уникально, остальные таблицы по 1-3 записи. Основная проблема судя по всему - очень много одинаковых значений по полям, которые используется при сортировке и фильтре.
Старый плюшевый мишкаДа план меняется просто при заменах inner-left. Порядок перебора таблиц и, соответственно, используемые индексы. При left порядок задан жёстко, при inner его определяет оптимизатор. Опираясь на статистику индексов. Но он не знает сколько у тебя в какой таблице дубликатов по индексам и, бывает, оптимизирует не в ту сторону. А у тебя их, дубликатов, сорок бочек арестантов. Но ты-то об этом знаешь, так и направляй оптимизатора через +0 для того, чтобы он не использовал заведомо вредные для этого конкретного запроса индексы. В смысле чтобы добиться среднестатистической оптимальности, по наиболее распространённому случаю. Кстати, сортировки тоже тормозят тем сильнее, чем больше дубликатов по этим полям. Если их нет, то почти что с сортировкой, что без.
Это пока для меня слишком сложно, я сейчас почитаю как работает FB (ссылку дали). Но что интересно, если у меня был только MS, я бы и думать не знал что имеется какой-то "оптимизатор", который иногда работает плохо и его надо както "поправлять" :)

Симонов Денис
Старый плюшевый мишка
Да все сделаю, посмотрю и проверю