FanatPHP

Это неправильно.
Надо завести отдельную таблицу user_read, в которой будет всего два поля - id пользователя и id новости.
Соответственно, добавление "в конец" будет обычной операцией вставки.

Правильный ответ:

$sql = "SELECT count(*) FROM `users` WHERE `login` = ? OR `email` = ?";
$stmt = $pdo->prepare($sql);
$stmt->execute([$login,$email]);
$user = $stmt->fetchColumn();

Что мы здесь имеем?

• Во-первых, запрос, защищенный от кривых ручек пользователя похапе, и, как следствие, от неправильного синтаксиса
  
• Во-вторых, запрос, защищенный от SQL инъекций.
  

пример в документации, конечно совершенно убогий, и его недостаточно.
Чтобы сделать минимально юзабельную и безопасную загрузку

1. проверять $_FILES['uploadfile']['error']
2. Проверять расширение файла на соответствие разрешенным по списку
3. Переименовывать файл, поскольку оригинальные имена - это адище и беспорядок плюс небезопасно.

Так и хранить.
www.mysql.ru/docs/man/TIME.html

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

На "памяти" это тоже не влияет. Приставка VAR означает, что строка занимает в БД ровно столько места, сколько байт содержится в строке (+ небольшой статический оверхед, естественно).

На скорость же в SQL влияют совсем другие вещи. В частности - наличие и размер индекса. Вот в отношении индексов как раз надо думать. В частности, по возможности использовать однобайтную кодировку, и ограничивать длину индексируемой части строки.

Для столь короткого описания сущности спроектированы верно.

Какое отношение к этому имеет количество запросов в БД - загадка.

Я правильно понимаю, чтобы все крутилось быстро, нужно чтобы таблица помещалась в оперативку с запасом?

Разумеется, нет. Это вообще никак не связанные вещи.
В отличие от новомодных словечек типа nosql, реляционные базы данных спроектированы так, чтобы работать с объемами, во много раз превышающими размер оперативной памяти.

Но чтобы работать нормально, систему надо настраивать. При этом

изменение схемы таблицы

Это одна проблема, со своими решениями, а

тяжелые запросы

-- СОВСЕМ другая, со совсем другими решениями

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

С "тяжелыми" запросами надо разбираться по отдельности.

Поменять localhost в конфиге на 127.0.0.1

А лучше поменять "новый хостинг" на нормальный, с пряморукими админами.

сначала пишем волшебную функцию

function pdo($db, $sql, $params = null) {
        if (!$params)
        {
             return $db->query($sql);
        }
        $stmt = $db->prepare($sql);
        $stmt->execute($params);
        return $stmt;
}

И после этого пишем почти такой же код, как и был

$md5_hash = md5_file($_FILES["fail"]["tmp_name"], true);
$res_double = pdo($db, 'SELECT * FROM `download__files` WHERE `md5hash`=?', [$md5_hash])->fetch();

Хотелось бы обьединить всех детей в один элемент.

Это вопрос не выборки, а обработки результатов.
База данных не отвечает за формат вывода запрашиваемых данных.

В PHP с использованием PDO для такого простого запроса можно получить группировку с помощью комбинирования режимов FETCH_GROUP и PDO::FETCH_COLUMN

Но при большем уровне вложенности или при необходимости получать какие-либо еще данные кроме имени, нужно будет писать обработчик руками.

Разница очень простая.

Функция mysqli_real_scape_string не предназначена для защиты против возможных sql-инъекций. И применять ее в таком качестве - прямой путь заполучить инъекцию.
В то время как одно из назначений функции mysqli_stmt_bind_param - это предотвращение sql-инъекций, поэтому применять её для этой цели можно и нужно.

Следует отметить, что у этого класса очень много других проблем.

1. Статическая функция для коннекта это картннный буратино, который никакой полезной функции не выполняет, а выполняет только вредную, каждый раз заново соединяясь с базой дынных. Надо хотя бы проверять, еслть ли уже соединение, и возвращать его.
2. prepare с пустым execute - это картннный буратино, который никакой полезной функции не выполняет, а выполняет только вредную, пропуская все инъекции на свете. В prepare надо передавать запрос с плейсхолдерами, а execute массив с переменными для замены.
3. echo "Ошибка соединения с БД: " - это это картннный буратино, который никакой полезной функции не выполняет, а выполняет только вредную. Пользователь из сообщения об ошибке ничего не поймет, а программист о ней ничего не узнает. Для вывода ошибок try должен быть один, глобальный, и выводить их в зависимости от окружения - на домашнем компике можно вываливать прямо на экран, а на боевом сервере только логировать.
4. Пользователь - это не база данных. Поэтому наследовать классу БД он не должен. и уж тем более нет ни малейшего смысла наследовать класс со статическими методами. Объект для работы с БД надо передавать в конструктор и присваивать переменной класса. Либо если это тупой синглтон, то ничего вообще не передавать, а просто вызывать его методы где надо, хотя это неправильно.

Подробне читать здесь (можно через гуглопереводчик)
https://phpdelusions.net/pdo/common_mistakes
https://phpdelusions.net/articles/error_reporting