Руслан .

Можно попробовать рекурсивный CTE, только нужно убедиться, что глубина рекурсии не очень большая, не больше 50 например.
Вот тут есть пример.
https://learnsql.com/blog/recursive-cte-sql-server/
Ну и реализация будет зависеть о вашей платформы, т.к. есть небольшие различия в синтаксисе.

А обязательно БД должна быть на сервере?
БД может встраиваемая на стороне клиента, например SQLLight.
SQLLight можно использовать и на стороне сервера у каждого пользователя будет своя БД.

Может воспользоваться формулами на подобии тех что описаны тут:
https://mapgroup.com.ua/glavnaya/astronomicheskie-...

По идее если у вас небольшой разброс точек по расстоянию, то формулы можно упростить. Т.е. условно можно вычислить координаты краевых значений квадрата в который должны входить точки и далее сделать селект по этим координатам из таблицы.

По идее тут все решается правильной группировкой:

select  pupils, extract(month from birth_date), count(1) as pupils
   from pupil
 group by pupils, extract(month from birth_date)
having count(1) > 1

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

SELECT SUM(CASE WHEN t1.`statut` = 'analyze'   
THEN 1 ELSE 0 END) as `ct_analyze`,
       SUM(CASE WHEN t1.`statut` = 'analyzed'   
THEN 1 ELSE 0 END) as `ct_analyzed`,
... ДРУГИЕ ПОЛЯ... 
   FROM `requests` t1 
   LEFT JOIN clients t2 
          ON t2.id_client = t1.id_client  
WHERE tnd t2.id_client IS NOT NULL
GROUP BY t1.id_client

Можно для каждого датчика в оперативной таблице хранить две даты: дата начала интервала постоянства и дата окончания этого интервала. Это такой интервал в котором значение датчика не меняется.
Т. е. грузим текущие данные и если по датчику значение не поменялось, то просто изменяем дату окончания интервала на дату текущей загрузки, если значение датчика поменялось(отличается от сохраненного в оперативной таблице) , то текущий интервал выгружаем в архивную таблицу, а в оперативной добавляем новую(изменяем существующую) запись для датчика у которой дата начала и дата окончания будет равна дате текущей загрузки, а значение текущему загружаемому значению датчика.
Т. е. в оперативной таблице всегда количество записей равно количеству датчиков, а в исторической весь скоп предыдущих значений.
Это должно защитить от того, что с течением времени скорость работы с оперативной таблицей будет деградировать, от того что там будет расти число записей.
Если же нужно какой-то отчёт строить или выгрузку за период или за прошлые даты, то тут уже нужно будет работать с исторической таблицей и это будет уже не очень быстро, но такие операции обычно не требуется часто выполнять.

Так как данные грузятся раз в 3-4 дня, наверное не очень критично, что загрузка будет выполнять не мгновенно. Тут наверное проще в несколько этапов сделать: на первом проходе построить список идентификатор датчиков по которым значение не поменялось, затем по этому списку проапдейтить дату окончания интервала на дату текущей загрузки, затем по датчикам которые не попали в список перелить строки в архивную таблицу и наконец поменять для изменённый датчиков в оперативной таблице значение счётчика и даты начала и окончания интервала.
Всё шаги можно делать массово.

В вашем примере, чтобы сработал поиск по шаблону внутри поля `meta_key` нужно так переписать:
`meta_key` LIKE '%pdf_url%'

Судя по коду у вас MySql.
Вот тут подробная информация:
https://www.w3resource.com/mysql/mysql-procedure.php
А тут небольшой пример:
https://www.tutorialspoint.com/how-to-display-mess...

Может быстрее будет вместо delete написать:
SELECT * FROM D
WHERE numbering > 1;
И сохранить результат select во временную таблицу.
После этого грохнуть все эти строки и вставить уже по одному экземпляру каждой из временной таблицы.

Для sqllite можно так попробовать.

SELECT
	MIN(id) ,
	price
FROM
	your_table
GROUP BY
	price
HAVING COUNT(price) = 1;

Запрос должен вернуть идентификаторы строк у которых уникальная цена.

Можно вот так попробовать:

SELECT product_id, 
        SUM(CASE WHEN field_id = 'f1' AND value_id in (v1, v2) THEN 1 ELSE 0 END), 
        SUM(CASE WHEN field_id = 'f2' AND value_id in (v3, v4) THEN 1 ELSE 0 END)
   FROM product
  WHERE value_id In (v1, v2, v3, v4) 
  GROUP BY product_id
 HAVING SUM(CASE WHEN field_id = 'f1' AND value_id in (v1, v2) THEN 1 ELSE 0 END) = 1
    AND SUM(CASE WHEN field_id = 'f2' AND value_id in (v3, v4) THEN 1 ELSE 0 END) = 1

Можно вот так попробовать, но оно не очень сильно сократит код:

cur.execute(f"UPDATE users SET field1=?, field2=?, fieldN=? WHERE user_id=? AND chat_id=?")

Можно было бы добавить ещё одну таблицу групп с полями x и group. Заджойнить вашу table с новой таблицей по полю x и сгруппировать по полю group. В вашем варианте в какой-то момент case может стать очень сложным и не читаемым, адля добавления новой группы нужно всегда запрос дописывать, а это не гуд.

Можно вот так попробовать:

SELECT Users.UserID 
  FROM Transactions   
  JOIN Users
    on Users.ManagerId = Transactions.Detail
 GROUP BY Users.UserID 
HAVING MAX(Transactions.CreationDate) < '2018-11-01'