FanatPHP

Запрос - какая-то адская фантасмагория. Нахрена здесь джойн, если из а берется только ид, который равен b.meta_value? Я уже не говорю про джойн с селектом и груп бай.
Такое ощущение, что запрос писал сумасшедший под веществами в состоянии белой горячки.

все что здесь нужно - это

SELECT SQL_CALC_FOUND_ROWS b.id, b.meta_name, b.meta_value
FROM b WHERE b.meta_name = '***'
ORDER BY b.meta_value DESC
LIMIT 0, 20;
SELECT FOUND_ROWS()

После объяснений в комментах стало понятно, что нам нужен подзапрос

SELECT SQL_CALC_FOUND_ROWS a.id, 
(SELECT b.meta_value from b where b.meta_name=a.id order by b.id limit 1) as lastprice
FROM a LIMIT 0, 20

Чтобы получить более подробное сообщение об ошибке, надо запускать команду с параметром -v

Нельзя.

В mysqli нет никаких колонок вообще. Это API, набор функций PHP. Его используют самые необучаемые пхпшники, которых отлучили от mysql_query, и которые не сумели освоить ничего более прогрессивного.

Колонки же есть в БД, которая называется mysql.

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

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

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

Объясняю:
Это не "PDO имеет подключение", а пользователь БД имеет доступ.
Если указанный при подключении пользователь имеет доступ к некоторой БД, то мы можем выполнять запросы к ней.

Отсюда можно сделать вывод: Если указанный при подключении пользователь имеет доступ к обеим БД, то такой запрос никакой не извращение, а совершенно стандартный SQL.
Если же доступ есть к только одной БД, то запрос не пройдет. Опять же, не из-за своей нестандартности, а по банальной причине отсутствия доступа.

А уж чрез PDO ли мы подключаемся, или через консоль - это уже без разницы.

Из кэша.
Вешать мемкеш на микроскопическую таблицу, которая гарантированно вся помещается в памяти, совершенно бессмысленно.

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

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

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

По confirmation_token рекомендую проверить после регистрации и до подтверждения.
Это поле должно быть заполнено только в этот период, в остальное время оно и должно быть пустым.

Как всегда, милилон ответов, все не в кассу.

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

mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);
$link->begin_transaction();
$stmt = $link->prepare("UPDATE `price` SET `price`=? WHERE `name`=?");
$stmt->bind_param("ss", $price, $name);
foreach ($jsondate as $k => $value) {
    foreach ($value as $bo) {
        $name = $bo['name'];
        $price = $bo['price'];
        $stmt->execute();
    }
}
$link->commit();

https://github.com/auraphp/Aura.SqlQuery
www.notorm.com
тысячи их

Для mysqli порекомендую свою SafeMysql
Если запрос не надо собирать динамически, то код получается куда проще , читабельнее и гибче, чем с любым билдером. Попробуйте к примеру выполнить через fluenpdo запрос insert ignore или on duplicate

Как думаешь, за что отвечает параметр --no-warmup?

> Если этот же запрос сделать в phpmyadmin:

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

Во-первых, phpmyadmin подставляет limit для твоего запроса, и запрашивает всего 20 строк из твоих 100 тысяч. Попробуй запросить все, и посмотри, сколько времени будет выполняться. Если вообще выполнится.
Во-вторых, даже для запроса с лимитом, 0.0002 -это мало. Результат явно идет из квери кеша. Один раз выполнил, дальше запрос закэшировался, и радостро выдает тупо результат.
В-третьих, как тут уже все сказхали, делать таблицу на сто тыщ строк - это совсем за пределами осмысленности. Кто будет это читать? Даже если делаешь XLS.

В общем, сначала изменить, сколкьо времени выполняется запрос ЦЕЛИКОМ, а потом сократить количество запрашиваемых строк до разумных значений.

Такой ерундой никто не занимается.

Во-первых, $zapros в запросе - это готовая инъекция.
Во-вторых, распихивать результат по отдельным массивам, это какой-то детский сад. В этом нет ни малейшего смысла, поскольку к любой колонке можно обратиться из единого массива

foreach ($all as $row) echo $row['Type'];
foreach ($all as $row) echo $row['Field'];

В-третьих, если надо получить только один столбец, то тут mysqli как всегда проигрывает PDO:

$stolbets = $pdo->($query)->fetchAll(PDO::FETCH_COLUMN);

Контроллер должен быть тонким.
А тонких не проблема сделать несколько - все равно никакой функциональности в них быть не должно - она должна лежать в репозитории и хелпере.

Так что делаем productRepozitory в котором пишем всю работу с БД
и productHelper, в котором пишем всю пхп логику
и дальше из контроллеров только дергаем методы хелпера

В двух словах - бессмысленный и небезопасный.

Класс не использует главные преимущества PDO - подготовленные выражения и возможность возвращать результат в десятках различных форматов. В итоге мы имеем SQL инъекцию в каждом запросе, а результат всегда возвращается только в виде списка.

При этом написана куча функций, чтобы сэкономить себе два слова при написании SQL запроса, ценой создания нечитаемой абракадабры.
Попробуй написать пример использования функции select() для запроса "SELECT access FROM user WHERE id=1" , а потом посмотри на него и честно скажи - можно ли без документации понять, что и откуда эта функция должна выбрать и с какими условиями.

Про бессмысленные телодвижения в select() я уж и не говорю.
То, что запрос зачем-то выполняется по два раза, а после этого идет странное условие с одинаковым кодом в каждой ветке - это уже мелочи.