psiklop, ну делать индексы просто от балды конечно не надо. Но и совсем без них тоже нельзя. Надо делать ровно те, которые нужны. Надо понимать, что дело не тлько в скорости выполнения запроса, но и в том, сколько ресурсов компьютера он отъедает. Если запрос выполняется 5 секунд, это значит он 5 секунд грузит комп.
Поэтому составной индекс, в котором уже лежат все нужные для запроса данные, и который позволяет запросу выполняться быстрее, полезен не только этим, а и тем что экономит ресурсы сервера.
Тем более что такой составной индекс полностью заменяет отдельный индекс по своей первой колонке.
Поэтому если есть например индекс по (phone, time) то отдельный индекс по phone не нужен. Но это уже детали.
кстати, непонятно, зачем в таблице индекс vid(id). вот этот явно лишний
Slash, вы изобрели контейнер, но зачем-то смешали его с автозагрузкой. С этой белибердой вы упадёте и сломаете себе все ноги.
Автозагрузка должна быть отдельно. Она нужна не только для объектов, которые должны быть в единственном экземляре. Тот же класс app вы как загружаете? Опять через include? Оставьте автозагрузку, то, что у вас было в spl_autoload_register
А в контейнере оставьте только работу с массивом, для объектов, которые нужны в одном экземпляре.
Сарказм - это свежо и остроумно. Но для человека, который за много лет использования mysql никогда не слышал слово explain, звучит довольно жалко.
Поэтому давайте вы его оставите для своих друзей-приятелей, а здесь сделаете то, что вам сказали
показать результат Show warnings после explain для всех запросов
показать результат SHOW ENGINE INNODB STATUS\G
увеличить innodb_buffer_pool_size до максимально возможных (если это выделенный сервер, то 80% от физической памяти, если совместно используемый - то хотя бы временно дать побольше памяти, скажем, половину) и попробовать свои запросы.
Ну вот и ответ.
Все ваши "мощные серверы" просто работают калориферами. Их память- сколько бы её не было - не используется.
Сделайте хотя бы пару гигов в пределах возможного, и сразу увидите разницу.
psiklop, не на "каждый", а на каждый тяжёлый. Если все данные берутся из индекса, а не по индексу мгновенно достаются из каждой записи, то запрос очевидно работает гораздо быстрее.
Но в любом случае самим индексам нужно где-то храниться. А "программисты на пхп", которые "не писали mysql" обычно об этом не задумываются.
я бы по привычке попросил автора вывести SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
зуб даю на отсечение, что там 134217728, как минимум на локалке.
Ну и в целом посмотреть SHOW ENGINE INNODB STATUS\G
Vitsliputsli, не буду спорить, но мое мнение прямо противоположное. Написать вот такую автозагрузку из одной строчки (он, собственно, не начал - он её уже всю целиком и написал) на мой взгляд как раз полезно.
Slash, просто подумайте, в чем смысл делать $class = new class; внутри функции. Ну создали вы этот объект, и что? Он тут же уничтожится после окончания работы функции. А в остальном верно.
Или класс всё-таки придется объявлять вне spl_autoload_register?
Что вы имеете в виду под "объявлять"?
Объявление класса - это его код. Разумеется, его надо писать, в отдельном файле.
Создание объекта этого класса? Разумеется, надо создавать. Там, где он будет нужен.
John Didact, зависит от того, что имеется в виду под "всё равно include/require"
По факту - да, разумеется, там внутри include/require.
Но там нету вот этих всех include_once (APP_DIR . 'process/class/thing.php'); с конкретными именами классов. Вся идея автозагрузчика в том и состоит, что классы подгружаются автоматически. Добавил новый класс в папку, обратился к нему из кода - и его определение само подгрузилось.
В 20 веке похапе программисты говорили "хтаксесс" когда хотели сказать "mod_rewrite"
В 21 веке похапе программисты говорят "композер" когда хотят сказать "автозагрузка"
ничего не меняется
Другое дело, что как и во всех других случаях "плохой производительности" проблема не в алгоритме, а в объеме обрабатываемых данных. То есть он зачем-то достаёт офигиллиард записей из редиса и кладёт в массив. Соответственно, сначала он должен ответить себе на вопрос - а нафига?
Очередной мечтатель, ковыряющий в носу.
Вчера увидел базу данных, CRM системы у него нет, автосервиса даже одного у него нет, но в мечтах он уже написал фейсбук на сто тыщ мильёнов пользователей, и острейшей проблемой для него сейчас является разделить базу для быстродействия.
при том что "задержки" у него только из-за на редкость кривых рук - нормальная БД и из миллиона строк отдаст нужную мгновенно
MRXWOLF, для базы данных - не дубль. Вы задали вопрос с тегом mysql. mysql про ваши ноги ничего не знает, и эти два номера для неё являются разными.
если у вас проблемы с ногами, то обращайтесь в поликлинику, а не сюда
Поэтому составной индекс, в котором уже лежат все нужные для запроса данные, и который позволяет запросу выполняться быстрее, полезен не только этим, а и тем что экономит ресурсы сервера.
Тем более что такой составной индекс полностью заменяет отдельный индекс по своей первой колонке.
Поэтому если есть например индекс по (phone, time) то отдельный индекс по phone не нужен. Но это уже детали.
кстати, непонятно, зачем в таблице индекс vid(id). вот этот явно лишний