как мне использовать два последних условия вообще не понимаю.
Это ограничения.
Первое чётко говорит, что не стОит пытаться найти такой URL, исключить его и решать задачу с 3 общими URL.
Второе нужно только для того, чтобы отсечь заведомо более длинный обратный путь решения - не от слов, а от URL-ов.
Совершенно бессмысленная конструкция. Отборы следует убрать в подзапрос.
Впрочем, есть некоторый шанс, что сервер проявит интеллект - но это зависит от статистики.
Создать индексы sc_proxy_request_log (IdSite, IpProxy) и обратный. Посмотреть по плану, какой используется. Убедиться, что форсинг другого не ускоряет. Оставить оптимальный.
Переписать на JOIN (меньше вероятность плохого плана).
Зависит от оборудования... кто-то ответит по SNMP, кто-то по какому-нить проприетарному протоколу, кто-то имеет IP или засветится по МАС, а кто-то либо не детектируется такими методами, а то и вовсе от них прячется...
Это ограничения.
Первое чётко говорит, что не стОит пытаться найти такой URL, исключить его и решать задачу с 3 общими URL.
Второе нужно только для того, чтобы отсечь заведомо более длинный обратный путь решения - не от слов, а от URL-ов.