ponaehal

В общем случае нельзя сказать однозначно.... в целом индексы предназначены для ускорения доступа к записям, в т.ч. при удалении и изменении. Но индекс, это отдельная структура на ведение которой СУБД тратит свои ресурсы. Например, при вставке данных в таблицу на которой "висит" 5 индексов, идет еще пять вставок в каждый из этих индексов. Причем вставить новую строку в индекс гораздо сложнее (с точки зрения ресурсов СУБД, возможно в зависимости от используемой СУБД) чем в таблицу, т.к. сначала необходимо найти место куда эту строку вставлять (сейчас говорю о наиболее распространенных b-tree индексах) и ссылки блоках индекса.
Более того, говорить о том, что индекс ВСЕГДА ускоряет доступ к записям - тоже неверно. Все зависит от вашего запроса и способа доступа к данным. Если данных для запроса достаточно в индексе, то СУБД выгребет данные вообще без доступа к таблице. Это во многих случаях (но не всегда :)) будет сильно быстрее чем извлечение данных непосредственно из таблицы. Если в запросе извлекается данных больше чем содержит индекс, то СУБД будет (если ее заставить) сначала обращаться к индексу для того что бы найти адрес строки в таблице, а затем полезет в таблицу и извлечет необходимые данные). Будет ли это быстрее чем просто искать по таблице? - во многом зависит от того сколько % записей должен вернуть запрос. Обычно рекомендация такова: если запрос должен вернуть больше 15-20% строк таблицы, то использование индексов нецелесообразно... Но даже тут есть 100500 тонкостей и особенностей.... В общем в этом вопросе мир тоже не делится на белое и черное... как то так...

Подозреваю что нужно усложнить задачу: Некоторые сотрудники могут отметиться на вход, но не отметиться на выход (по ошибке выйти с кем-нибудь за компанию) и наоборот... да?
и да, в любом случае можно обойтись одним запросом.

Мы делали наверное не по науке, но зато понятно для всех участников.. .и работало на всех почтовых клиентах...
Создавали контакты - Переговорная1, Переговорная2 и т.п. и при назначении встречи в список обязательных участников ставили переговорную. Обязали всех сотрудников при назначении встречи, смотреть доступность ресурсов в т.ч. переговорных комнат (кнопка "Помощник по планированию" в аутлуке). Конфликты из-за переговорных исчезли...
При необходимости, можно назначить ответственного (секретаря) который бы акцептовывал или отказывал приглашения на собрания от имени переговорных (например на случай если несколько переговорных периодически нужны для встречи непредвиденных посетителей). В общем дальше любые проблемы вполне разруливаются регламентно.

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

Говорю про Oracle, но подозреваю во всех БД примерно так же
Раз и навсегда отсортировать данные не получится. Данные в таблице неотсортированы. Можно это сделать искусственно. Перенести данные в другую таблицу, потом данные в исходной таблице удалить и залить из второй в нужном порядке. Но смысла от этого немного - когда кто-нибудь еще добавит данные в эту таблицу, ваша сортировка поедет. В общем случае, гораздо правильнее воспользоваться индексом (в нем данные осортированы) и следить что бы он использовался в запросах.

Погуглите "иерархический запрос"
например так: https://urvanov.ru/2017/05/28/%D0%B8%D0%B5%D1%80%D...

по первому вопросу может сработать (В зависимости от используемой БД или стандарта SQL):

select t1.* from table1 t1
INTERSECT
select t2.* from table2 t2

Насколько я помню молодость HAVING фильтрует по значениям агрегаторов (SUM, MAX и т.д.), а в вашем случае нужно просто добавить фильтр в условие WHERE .... AND group in (1,2)