Обединенить данные в под запросе?

thx. С UNION работает, но долго. В моем случае ~0,850 с.
Пока сделал такой запрос:

SELECT * FROM table WHERE id IN (select id1 from table2) OR  id IN (select id2 from table2)

Отрабатывает за ~0.370 с.

Johnick, с union или union all?

Vitsliputsli, пробовал оба варианта, время выполнения запроса не менялось.

Johnick, странно, не вижу большой разницы между запросами, а вот с union большая разница, не должно быть там такое же время. Надо будет потестировать.

Vitsliputsli, перед данным запросом у меня еще идет создание пары временных таблиц.
Сейчас увеличил кол-во строк для поиска 100k+:
UNION ALL:

/* Affected rows: 101 990  Found rows: 12  Warnings: 0  Duration for 5 queries: 2,813 sec. */

UNION:

/* Affected rows: 101 990  Found rows: 12  Warnings: 0  Duration for 5 queries: 2,891 sec. */

Мой вариант выше с OR:

/* Affected rows: 101 990  Found rows: 12  Warnings: 0  Duration for 5 queries: 2,157 sec. */

Тут уже разница меньше получилась, но так же быстрей.

Johnick, тоже немного потестил, получил достаточно странные результаты. Пробовал на MariaDB, MySQL, PostgreSQL. На каждой из них более выигрышными оказывались разные запросы. На MySQL действительно более быстрым получается вариант с OR, на остальных он сильно проигрывает из-за материализации подзапросов, в MySQL оптимизатор почему-то выбирает не материализацию, а subquery. На PostgreSQL запрос с OR уходил в астрал и не возвращался (более 2 минут ждать не стал, план показал дикую стоимость в сотни тысяч раз выше нормальных, на Partial Aggregate из-за Parallel Seq Scan). Решил переписать на более оптимальный и однозначный по работе оптимизатора (так мне казалось):
select count(*) from test
left join test1 on test.id=test1.id
left join test2 on test.id=test2.id
where test1.id is not null or test2.id is not null
И, действительно, он был быстрее всех запросов на всех СУБД, всех... кроме OR на MySQL.

Использовал таблицы с первичным ключом на 1 млн. строк с рандомными id. Все тесты на одной машине. count(*) чтобы IDE не подменял запрос и не ждать фетча. Получилось так:
MariaDB 10.3.14:
JOIN: 3.4c, OR: 9.4c, UNION: 4.6c, UNIONALL: 5.4c
MySQL 8.0.15:
JOIN: 8.3c, OR: 7.8c, UNION: 9.8c, UNIONALL: 15.1c
PostgreSQL 10.7:
JOIN: 1.6c, OR: >120c, UNION: 5.0c, UNIONALL: 2.1c

В общем, яснее не стало, нужно еще разбираться с планами запросов.

Это я тоже пробовал. В данном случае id объединяется построчно, например:
1,2
3,4
5,6
и дальше основной запрос учитывает только первый id, т.е. выбирает записи с id = 1,3,5