Ипатьев

Чтобы получить одну строку из результата запроса, в mysqli есть функции

• fetch_assoc(): возвращает всю строку в ассоциативный массив
  
• fetch_row(): возвращает нумерованный массив (список)
  
• fetch_obj(): возвращает объект класса stdClass
  
• fetch_column(): возвращает значение из первой колонки запрошенной строки
  

В общем случае случае осмысленный код для получения значения единственной колонки будет таким

$sql = "SELECT link FROM tablet where id=?";
$result = $conn->execute_query($sql, [$a]); 
$link = $result->fetch_column();

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

function Axelmo($conn) {
    $sql2 = "SELECT link FROM tablet ORDER BY rand() LIMIT 1";
    return $conn->query($sql)->fetch_column();
}

Ну и чисто для иллюстрации, как сделать запрос с ограничением по id

function Axelmo($min, $max, $conn) {
    $sql2 = "SELECT link FROM tablet where id >= ? AND id <= ? ORDER BY rand() LIMIT 1";
    return $conn->execute_query($sql, [$min, $max])->fetch_column();
}

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

На вопрос из заголовка уже ответили, а вот к сути вопроса есть вопросы.

В первую очередь надо задать себе вопрос, а зачем вам отдельный класс на каждый вид запроса? Если там достаточно одного метода?

Если у вас отдельный квери билдер на коленке, то вы можете сделать его отдельным классом, унаследовав от него сам враппер. В котором реализовать методы для запросов

Зачем вы задаёте не тот вопрос, с которым у вас проблема?:)

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

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

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

В данном конкретном случае проблема может быть в "переносе" данных между серверами, насколько можно судить из этого невнятного вопроса

Вопрос из серии "У меня есть своя дурацкая точка зрения, которую я ни сформулировать толком не могу, ни подкрепить никакими доводами. Давайте, переубеждайте меня!"

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

Но могу вас утешить. Всё это говорится про более-менее сложные приложения.
Говнокодить свою домашнюю страничку про котиков, или интернет магазин по продаже мёда с пасеки любимого дядюшки вы можете как угодно, хоть в SQL, хоть в Brainfuck-e.

Вопрос с подвохом.
Я сейчас сообразил, что узбекский - это не китайский же. Либо латиница, либо кирилица.
То есть проблема скорее всего не в кодировке.
А, как выяснилось в комментариях - тупо в неправильном выполнении запроса, и инъекциях.
то есть переменные надо не напрямую пихать в запрос, а через специальные маркеры, как написано здесь https://habr.com/ru/articles/662523/

Если же говорить про кодировки, то
у поля (или таблицы) должна стоять не "одинаковая" кодировка, а utf8mb4
в РНР при соединении должна устанавливаться кодировка utf8mb4
в заголовках веб-сервер должен отдавать кодировку utf-8
если текст пишется прямо в РНР коде, то этот код тоже должен быть в кодировке utf-8

Если нормально сформулировать вопрос, то речь идет о банальном деплое
И автору бы сначала поучиться разворачивать свое единственное приложение, а потом уже начинать мечтать про междупланетный шахматный центр на тыщу инстансов.

При том что задача в общем случае решается элементарно. Добавлением еще одной секции в плейбук того же Ansible. Что даст автору ту самую заветную "одну кнопку". А точнее две - развернуть новый инстанс и обновить все существующие.

А если еще внимательнее посмотреть на проблему, то возникает закономерный вопрос - а зачем автору вообще миллион виртуальных хостов, если речь идет о банальных поддоменах? Которые прекрасно реализуются в рамках единственного виртуального хоста. То есть можно либо добавить поддержку субдомена в текущее приложение, либо, на худой конец, сделать multi-tenant приложение, где у каждого поддомена будет своя БД.
При этом вся кнопка будет заключаться в добавлении имени субдомена в базу данных

Учитывая, что тот же РНР прекрасно обрабатывает запросы вида ?foo[]=bar&foo[]=bar2, то уникальность явно не является обязательной.
А то что он видит как один (только не первый, а последний), то это как раз совершенно очевидно и банально.
Если вы в коде напишете
$array['foo'] = 'bar';
$array['foo'] = 'bar2';
То разумеется в $array останется только второй вариант, который тупо перезатрет первый. И Оппач тут совершенно не при чем.

Но вам никто не мешает написать свой парсер QUERY_STRING и брать из него неуникальные значения.