Ипатьев

потому что переводы строк конечно же

Во-первых, зачем тут первый запрос?
Во-вторых, кроме количества совпадений надо наверное запрашивать и сам id? Ну по логике? если мы хотим вывести id, то надо наверное это поле указать в SELECT?
В-третьих, надо добавить группировку, GROUP BY
В-четвёртых, если надо вывести любые значения из первой, а не только те, у которых есть записи во второй, то нужен LEFT JOIN

Как правильно заметили выше, неопределенный по размеру массив данных в БД - это таблица.

select count(*) as cnt from tbl_file
Выводить обычным порядком, судя по предыдущим вопросам, работать с mysql из PHP вы умеете.

Никакие транзакции тут не нужны. транзакции вообще не про это. Почему-то новички упорно путают транзакции с блокировками. Транзакция - это про целостность данных. А чтобы два процесса не считали одну строку - это блокировка.
Но явные блокировки тут тоже не нужны.

Сначала забираем запись на себя
update urls set proxy=proxy_id where done=null and proxy=null limit 1
потом уже её селектим, работаем, и в конце отпускаем
select * from urls where proxy=proxy_id
...
Update urls set proxy=null, done=1 where proxy=proxy_id

Насколько схема корректная с точки зрения проектирования?

Непонятно, к чему здесь FeatureProps. Зачем тут многие ко многим?
ProductProps (product_id, feature_id, prop_id) достаточно

если я захочу заменить точечно на определённых товарах?

Скорее всего, это будет уже новое свойство.
Если захочется переименовать для отдельных товаров, то понадобится таблица feature_names(feature_id, product_id, name), которую лефт джойнить к запросу, и брать имя из неё, если есть.

Имена таблиц тоже лучше делать в нижнем регистре. Сбережёт некоторое количество нервных клеток.

На всякий случай предупрежу: Если продукт дойдёт до продакшена, то искать всё равно будете Эластиком. И как следствие - выкините весь EAV за ненадобностью, а все свойства сложите в JSON
Но для практики конечно поколупаться конечно полезно

Во-первых, такой подход называется не функциональным, с процедурным. Функциональное программирование - это совсем другое.
Во-вторых, сама по себе разбивка кода на функции ни к какому замедлению не приводит.
Проблема не в том, что много функций, а в том коде, который в них написан.

В целом, цифры какие-то дикие. Что 8 секунд, что 16, что 3. Для записи одного "продукта" нужно максимум 0.1 секунды, если всё очень сильно тормозит

Тут у многих правильная мысль, что надо считать количество, но все считают общее.
А надо по каждому свойству отдельно.

В принципе, поиск по одному значению - это просто, по джойну на каждое свойство. Но вот когда выбор из нескольких...
Как-то так должно по идее работать

SELECT p.*, sum(po1.classifier_id=1) num1, sum(po2.classifier_id=2) num2 FROM products p
    left JOIN product_options po1 on po1.product_id = id and po1.classifier_id=1 and po1.option_id in (1,2)
    left JOIN product_options po2 on po2.product_id = id and po2.classifier_id=2 and po2.option_id in (10,11)
group by id having num1 > 1 and num2 > 1;

Разумеется, API.
Сейчас даже в рамках одного "хостинга" многие проекты переходят на микросервисную архитектуру, ходя в лежащую рядом БД не напрямую, а обращаясь по НТТР к сервису, который уже и лезет в БД.

Тем более что тут нужна не вся БД, а всего-то одна таблица. То есть код пишется за полчаса.
На клиенте file_get_contents, на сервере такой же код, что и при обычной авторизации, но возвращает не Location а true.

Правильно все однородные данные хранить в одной таблице.
Связи в БД строятся на основании содержимого таблиц, а не на основании их имён.
Иначе потом приходится "бегать по всем этим таблицам и собирать записи".

Так же при проектировании БД следует опираться на требования архитектуры, а не на влажные эротические мечты про "сумасшедшие масштабы". Если когда-нибудь проект достигнет сумасшедших масштабов, то к этому моменту вся архитектура будет переделана не один раз. И проблема комментариев будет решаться в зависимости от реальных проблем с которыми столкнётся проект, а не в соответствии с фантазиями, которые были у кого-то на начальном этапе.

Никак не увеличивать, при запросе добавлять к исходному значению число прошедших дней

Задавать вопрос "почему мой код не работает" бесполезно.
Просто потому что код может не работать примерно по миллиону причин. Запаришься все перечислять.
Причём эти причины к самому коду могут не иметь никакого отношения.
Всегда надо задавать вопрос "как я могу узнать, почему код не работает".

Чтобы узнать, почему РНР код не работает, надо прочитать сообщение об ошибке РНР. В данном случае мы его не видим, а видим только сообщение веб-сервера о том, что РНР завершился с ошибкой.
Чтобы увидеть ошибку РНР, надо сделать две вещи:
1. Убедиться, что РНР генерирует сообщения об ошибках. Для этого во-первых, всегда должен стоять максимальный уровень генерации ошибок, error_reporting(E_ALL);, и во-вторых, программист не должен сам себе стрелять в ногу, насильно подавляя сообщения об ошибках. И никогда не использовать оператор подавления ошибок, @.
2. На время разработки поставить режим вывода ошибок на экран, ini_set('display_errors', 1);. На боевом сервере, соответственно, этот режим должен быть выключен, а логирование наоборот - включено.

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

Отдельно отмечу, что в таком виде регистрацию делать бессмысленно, тут сплошная SQL инъекция, то есть кто угодно сможет узнать чужой пароль, залогиниться под чужим именем или вообще зайти без пароля. Все SQL запросы, в которых участвуют переменные, в обязательном порядке должны выполняться через подготовленные выражения, с заменой переменных на знаки подстановки.
Кроме того, пароль в обязательном порядке должен стойко хэшироваться, функцией password_hash()

В целом п.3
Обеспечивать случайность - это затратная операция, её никто просто так делать не будет. Скорее всего, имелся ввиду неопределённый порядок, а не случайный. Который как раз и подходит под п.3

Если сразу после добавления, то может в порядке вставки, но это не точно, поскольку запись может идти не линейно, а на место записей, помеченных, как удалённые. Плюс после удалений/обновлений физический порядок записей в файле тоже может меняться, и соответственно, порядок выдачи.
В целом ответ - никак не сортирует, берет первую попавшуюся.