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