amazinginternetsites: переделать с учётом логических конструкций и с правильным синтаксисом, ссылки на мануалы выше давал. Ну а если вам срочно надо, и вникать нет времени - обратитесь на фриланс биржи.
Flasher: да, скобки не добавили. $1 - это означает номер группы, в данном случае такой регексп нужен
/(@][\w]+)/u, $1 будет означать, что будет взять содержимое из первой группы (@][\w]+)
Flasher: $1 заменяется на содержимое группы, которая обозначена в скобках. То есть regexp полностью такой же, как у вас в условии(непонятно зачем вы только используете ограничитель по символу для собаки, если у вас там только 1 символ и есть - собака). Не нравится с группами, можно так:
preg_replace_callback('/@[\w]+/u', function($matches){ return ''. $matches[0] . '';}, $string);
результат будет тот же.
Lev Lybin: только сейчас доглядел, у вас что, все индексы одинарные?
Если так - то естественно, что mysql не будет их все использовать как нужно. Using intersect говорит об этом. Постройте составной индекс слева-направо по столбцам выборки, то есть в случае WHERE actions.user_id = '222222' AND actions.type = 'BonusDist' ORDER BY actions.created_at DESC индекс должен быть user_id, type, created_at и тогда оптимизатор всегда будет использовать его.
тостер хабрович: попробуйте не в ,htaccess а в httpd.conf указать, и проверьте, включён ли mod_php вообще (a2enmod должна и там работать, по идеи, но точно не скажу)
тостер хабрович: ну тогда, вам нужно включить обработку php кода вашим сервером, полагаю что у вас apache2, тогда проверьте включён ли mod_php:
sudo a2enmod php5
Роман Янчук: Индекс нужен в любом случае. Сортировка по первичному ключу (без других индексов) будет работать только если у вас нет блока WHERE и JOIN'ов или у вас в блоке WHERE только первичный ключ. Составной индекс вам не нужен. Обычный индекс хранит primary key по умолчанию(без участия извне)
Роман Янчук: нет, на mebmer нужен индекс, просто индекс mebmer содержит в себе помимо значения поля member ещё и значение поля primary key, в нашем случае - id. Поэтому у вас в данном случае происходит выборка и сортировка по одному и тому же индексу, что и даёт такой результат.
Так же можете пробовать EXPLAIN SELECT id FROM vip WHERE member = '1' LIMIT 1;
Explain вам покажет, что к таблице данный запрос не обращался, и все данные вывел из индекса (так называемый "покрывающий" индекс).
Тёма Макеев: x-cache и apc умеют кешировать опкоды, но так же и умеют в ключ\значение хранилища. Мемкешед - это отдельная ключ\значение бд, php к ней подключается по собственному протоколу мемкешед.
Всё это подразумевает не нативное, а ручное кеширование в коде (получил данные, положил их в кеш).
Есть нативное кеширование в mysql - это собственный Query Cache, но в некоторых случаях, без него быстрее, чем с ним.
MaxKorz: i.imgur.com/INJcbVZ.png вот всё, что из плагинов есть, замазаны два лично написанных, так как их не могу разглашать, но сессии они не используют.
ALTER TABLE table_name DROP INDEX index_name;
таким образом удалите данный индекс, и проставьте новый, но уже без уникальных полей (только предварительно обдумайте, зачем предыдущий создатель сделал там именно уникальный индекс, возможно он жизненно необходим, а ошибка не в базе, а в самой логике приложения)