Помимо предложений выше. Я бы по оптимизировал where
Условия простые и эффективные с точки зрения индексов подвинуть наверх, далее по возрастанию неэффективности.
Ведь при каждом новом условии объем выборки уменьшается, значит серверу придется делать меньше переборов
потом id in и id not in я бы свел к двум, это будет быстрее, чем несколько раз перекапывать выборку (особенно если она большая или вообще не лезет в память) для сравнения со списком. Т.е. сначала готовим списки, потом один раз сравниваем.
Конечно сам сервер должен быть оптимизирован под такие запросы, чтобы хватало выделенной памяти.