Melkij

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

Вопрос-то в чём?
exec для перезапуска. Механизмы редактирования файла - любые.

Лишь бы прав хватало на это дело у пользователя, от имени которого работает PHP

Коннектор интерфейса - идентичен полностью.
Коннектор питания - идентичен, но могут разведены не все линии питания.

Если желаемый переходник даёт только 7-пиновый коннектор для данных - совместимы без проблем. Соответственно, питание при этом подключается каким-то другим способом.
Если переходник даёт и данные и питание (при этом, только от одного или пары USB) - совместимы механически, но работать не будет. В этом адаптере нет +12В питания, только +5В, обеспечиваемые портом USB. Большинству 2,5" дисков этого достаточно (исключение - серверные), 3,5" - нет.
Если помимо USB подключается ещё чем-то - то надо отдельно уточнять, чем и подаёт ли на диск +12В

SELECT DISTINCT keywords.id
  FROM keywords
  JOIN images_keywords ON keywords.id = keyword_id
  JOIN images ON image_id = images.id WHERE images.space = 1

С какой целью вы вообще в этом подзапросе джойните таблицу keywords?

SELECT DISTINCT keyword_id
  FROM images_keywords
  JOIN images ON image_id = images.id WHERE images.space = 1

Тот же самый результат будет.

Вообще, джойн с подзапросом вам и не нужен

SELECT SQL_NO_CACHE *
FROM keywords
WHERE keywords.id IN (
  SELECT DISTINCT keyword_id
  FROM images_keywords
  JOIN images ON image_id = images.id WHERE images.space = 1
)

Для mysql актуальных версий in subquery должен работать адекватно.

Сформировать CSV и скормить через LOAD DATA INFILE напрямую в базу.

Если с load data не получается, то в одной транзакции скармливаете множественные insert'ы (насколько множественные - см max_allowed_packet)
5 мб данных не так уж и много.

Во-первых, снимите с каждого отдельного диска посекторную копию.
Только после этого можно что-то делать.

Попробуйте запуститься с linux с linux raid. Судя по объёму дисков, массив старый. Есть вероятность, что массив подцепится автоматически.

Дык бекап или "в случае отказа одного из жостиков ничего не потерять"?
Это две разные задачи.

понял что данная материнка не будет работать с такими большими дисками.

Почему вы пришли к такому выводу?

select concat('dd/', fieldname) ...

select st.name, count(0) from Sms join Sms_status st on status_id = st.id where st.name in ('sent','not_sent', 'new') group by status_id

Аналогично и первая толпа запросов сворачивается в один простой SQL.

А с учётом сущности данных - имеет смысл их перенести в отдельную таблицу аггрегации и не пересчитывать в рантайме весь массив.

Частота обычно не проблема.
А вот то, что память разных стандартов - проблемой может стать.
DDR3 - 1.5V, DDR3L - 1.35V
Разное напряжение на разные слоты материнка обычно давать не умеет. Соответственно, или первый модуль получит мало питания или второй - много. Может даже и заработают, но режим нештатный и лучше бы так не делать.

На id_advert[] заменить невозможно?

Разгребать из $_SERVER (емнип, QUERY_STRING) вручную.

testcase:
foo.php
foo.php/
foo.php/bar

Создавайте в форме поля с именем elem[] По желанию, с каким-нибудь ключом.
PHP любезно упакует эти поля в массив $_POST['elem'] (ну или $_GET или чем ещё вы форму отправляете) и не надо будет костыли лепить.

PDOStatement реализует Traversable.
Поэтому foreach ($stmt as $value) { вполне корректно делать. Осталось понять, зачем вы сделали $stmt = $stmt->fetch();