Akina

SELECT *, 'db1' AS dbasename
FROM db1.tablename
WHERE phone = '123-45-67'
UNION ALL
SELECT *, 'db2'
FROM db2.tablename
WHERE phone = '123-45-67'
UNION ALL
...

Если список баз не фиксирован и должен формироваться в рантайме - то хранимая процедура с запросом по INFORMATION_SCHEMA.TABLES и динамическим SQL.

parsed - 0 - страница еще не спаршена, 1 - страница спаршена.

Не так.

NULL - не парсилась.
0 - парсинг выполнен.
>0 - взято на парсинг соединением (функция CONNECTION_ID()) номер N.

Соответственно попробовать зарезервировать запись на парсинг:

UPDATE urls 
SET parsed = CONNECTION_ID()
WHERE parsed IS NULL
ORDER BY datetime_added LIMIT 1;

Получить зарезервированную запись и начать её парсинг:

SELECT *
FROM urls
WHERE parsed = CONNECTION_ID();

Если вернётся более одной записи - в системе большие проблемы, надо звать администратора задачи. Если пустой набор - значит, запись перехватили, пробуем резервировать заново (тоже, кстати, повод позвать админа задачи - так не должно быть). Иначе - парсим полученную запись.

По окончании парсинга соответственно

UPDATE urls 
SET parsed = 0
WHERE parsed = CONNECTION_ID();

Ну и периодически выполняется event procedure, который находит записи, формально помеченные как обрабатываемые, но, судя по времени, обработчик подвис. Такие записи возвращаются на обработку

CREATE EVENT clear_parsing_flag
ON SCHEDULE EVERY 1 MINUTE
DO
UPDATE urls
SET parsed = NULL
WHERE parsed > 0
    -- считаем, что 5 минут более чем достаточно
  AND datetime_start_parsed < CURRENT_TIMESTAMP - INTERVAL 5 MINUTE;

Само собой никаких пулов соединений, никаких открыть-закрыть - все операции выполняются в рамках одного persistent connection. Автовосстановление соединения при обрыве также запрещено.

Если соединение развалилось, неважно по какой причине, бросаем обрабатываемую запись (шедулер вернёт её в необработанные), соединяемся заново и начинаем с самого начала, с резервирования.

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

SELECT ebids.*
     , SUM(comment_system.itemtype='qqq') AS has_qqq_comment 
     , SUM(comment_system.itemtype='www') AS has_www_comment 
     , SUM(comment_system.itemtype='eee') AS has_eee_comment 
FROM ebids
JOIN comment_system ON comment_system.item_id = ebids.id
WHERE ebids.status != 'auto'
GROUP BY ebids.id
ORDER BY ebids.id DESC
LIMIT 0, 100

Что будет лучше в плане скорости и нагрузки

Определитесь. Или в приоритете скорость, или нагрузка. Но не то и другое одновременно.

Если приоритетна скорость - то данные должны быть предварительно (а не в момент поступления запроса) загружены в PHP и там проиндексированы, причём должен использоваться алгоритм индексирования, обеспечивающий высокую скорость поиска. Поскольку речь идёт о поиске по подстроке, то, вероятно, это суффиксное дерево или аналогичная индексирующая структура.

Если приоритетна нагрузка - то поиск следует производить средствами СУБД.

Пример.

На стороне PHP имеется массив строк:

aaa
bbb
ccc

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

Первое - объединяем/сериализуем этот массив в одно значение. Допустим, выбрали JSON массив. То есть ["aaa", "bbb", "ccc"]
И именно этот JSON мы передадим в запрос.

Далее на стороне MySQL надо разобрать JSON на элементы и вставить в таблицу. Это делается одним запросом.

INSERT INTO destination_table (single_value)
SELECT single_value
FROM JSON_TABLE( ? ,
                 '$[*]' COLUMNS ( single_value VARCHAR(255) PATH '$' )) jsontable;

И... а, собственно, всё.

Осталось только убедиться, что размер строкового представления данных не превышает установленный в MySQL размер входящего пакета, и, если превышает, то соответствующим образом подрихтовать сессионную переменную max_allowed_packet. Впрочем, дефолтно там 67108864 байтов, это порядка 1480 байтов на элемент - должно хватить.

При всей неизбывной глупости такого решения:

INSERT INTO main (table1_id, table2_id) 
WITH 
cte1 AS ( SELECT id, ROW_NUMBER() OVER (ORDER BY id) rn FROM table1 ),
cte2 AS ( SELECT id, ROW_NUMBER() OVER (ORDER BY id) rn FROM table2 )
SELECT cte1.ID, cte2.ID
FROM cte1
JOIN cte2 USING (rn);

WITH
cte AS (
  SELECT *, COALESCE(LEAD(id) OVER (ORDER BY id),
                     MIN(id) OVER ()) next_row_id
  FROM comments
)
SELECT * 
FROM cte

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

Перевернись, не с той стороны смотришь. Наоборот, юзеру должны отображаться посты только его групп.
Решается элементарно.
На текущей структуре это будет

FROM post
JOIN user ON user_id = {текущий пользователь} AND FIND_IN_SET(post.group_id, user.group_ids_csv)

Однако функция в связи - это прощай индексы и здравствуй фуллскан.

ID username group
1 admin 1,2,3

Дурацкая схема хранения.
Если есть связь M:N, то должна быть связующая таблица (user_id, group_id).

Разумнее использовать WHERE NOT EXIST, который скорее всего будет более эффективен:

SELECT [DISTINCT] number
FROM table t1
WHERE service NOT IN (1,2,3)
  AND NOT EXISTS (
    SELECT NULL
    FROM table t2
    WHERE t1.number = t2.number
      AND t2.service IN (1,2,3)
)

Индекс по (number, service) - весьма желателен.

Если service - целочисленное поле со значениями от единицы и более, то для даных конкретных условий можно построить и более эффективный запрос:

SELECT number
FROM test
GROUP BY number
HAVING MIN(service) > 3