d-stream

Сам SQL прост, там как у Эллочки Людоедовой минимальный словарный запас:
select
insert
update
delete

Остальное не столько сам sql, а скорее понимание общей теории реляционных [баз данных] отношений.

Рискну предположить что упрощизм опечатки прячет важные детали.
Все-таки стоит привести образцы двух полных запросов (ну и следом видимо структуру таблиц-индексов)

Естественно в случае что повторяемость эксперимента присутствует - 10 раз из 10 в любом порядке соотношение времени выполнения сохраняется.

И само собой после сравнения планов выполнения этих запросов.

Как уже подметил Лентюй - SQL изначально был ориентирован на своего рода "ботаников" - чтобы они писали "что они хотят увидеть". Остальное - дело интерпретатора-планировщика.
И начинать надо именно с этого. В 90% случаев планировщик sql сможет построить план запроса так, что он окажется гораздо оптимальнее, чем наоптимизирует любитель.
И только в случае действительно медленного отклика - можно будет о тонких местах и погрузится в волшебный мир индексов-хэшей-лимитов памяти-хинтов и т.п. )

Ну как минимум попросить reader прочитать [очередную] строку (Read()) и уже тогда добывать из прочитанной строки поля.

Без обдумывания: group by и звездочки в селекте - не есть нормально. Хотя mysql типа прощает.
Ну и дальше нагруппировалась сотня строк по pp.track_id - то есть в итоге одна строка, у которой "вовнутрях" два десятка разных pp.position - и какую из них и почему sql должен использовать как критерий сортировки (order by)?

Можно слегка модифицировать ORDER BY random() LIMIT 1 используя его для выборки PK, который уже и использовать в основной выборке

p.s. а какова бизнес-сущность таких рандомных выборок?

delete from table where id in (select top 1 id from table where <нужное условие>)

group by case when x in (500,400,101) then 'three' case when x in (500,400) then 'one' else '' end

Наиболее затратное по времени выполнения это расчет остатков за весь период на указанную дату в разрезе по номенклатуре.

Во-первых зачем это в crm? Во-вторых - зачем это каждый раз на заданную дату, а не на текущий момент?

Гм.. а в чем непонятность?
Если речь о партионном учете - т.е. в каждой продаже фигурирет отсыл на конкретную партию покупки - то собственно вычитая из отбора покупок до нужной даты отбор продаж до этой же даты через связку партий - получим остатки по каждой конкретной партии. Сумма произведений остатков в каждой партии на цену покупки - и даст сумму остатков.
Если учет по среднему - то трактовок может быть несколько:
- глобальное среднее по всем партиям прихода до нужной даты умножаем на количественный остаток (это попроще)
- закладываемся на FIFO и тогда вначале исключаем обнулившиеся "партии" (по хронологии поступления) и потом для оставшегося считаем среднее

https://dev.mysql.com/doc/refman/8.0/en/window-fun...

Эээээ

update [Contact Message In]
set Processed=1, [Received Message Date Time]=getdate()
where Processed=0

Можно попробовать в excel посортировать )

А вообще order by c перечислением критериев сортировки звучит именно как сортировать вначале по первому критерию внутри одинаковых - по второму и так далее...

А то что хочется - это напрашивается в качестве первого критерия - нечто синтетическое из всех трех критериев. К примеру если представить эти метрики в виде осей координат - то в качестве синтетической метрики можно использовать удаленность от начала координат - то бишь корень квадратный от суммы квадратов (в данном случае для ордеринга можно корень исключить).

Судя по https://www.sqlitetutorial.net/sqlite-window-funct... sqlite уже умеет lag/lead - тогда все должно получиться вполне изящно.

в случае все id - можно Как сделать SQL запрос на три таблицы?

Напрашивается оконная функция:
группируем по pbx_call_id
сортируем по callstart
и берем только первые (row_number()=1)

Не совсем уверен, что прокатит row_number() в where, но канва вот примерно такая:

SELECT 
id OVER(PARTITION BY pbx_call_id ORDER BY callstart ASC) 
FROM table 
Where ROW_NUMBER()=1

то бишь получаем id (я же правильно понимаю что это pk?) первых записей для каждого звонка ну и дальше их или к ним join'им саму таблицу

Стоит около шоссе толпа братков. Мимо них проезжает на авто мужик, останавливается и спрашивает:
- Я могу проехать по этой дороге в Солнечногорск?
Братва посовещалась немножко. Потом выходит из группы один и говорит:
- Слышь, мужик, братва не возражает.

В чем вопрос?

p.s. hint ms sql умеет recursive cte и в том числе управляется через maxrecursion
https://docs.microsoft.com/ru-ru/sql/t-sql/queries...

я бы начал с некоего переосмысливания - что же он такого делает
думаю для понимания можно вынести сабселекты в джойнах во временные таблицы в памяти (@table)

ну и посмотреть на предмет distinct в главном селекте - есть большие подозрения что от него можно избавится сгруппировав значения