Тяжёлый MYSQL запрос

апгрейд тарифа. И увеличение кеша под запросы. Либо обращайтесь в раздел "услуги веб-разработчика" а не "системное администрирование".

это может быть и проверкой прав доступа. может ее отключить?

А вообще, 6805 строк за 9 секунд - по мне так это скорее перегруженный VPS, чем тяжелый запрос. Для физического сервера такие запросы, как правило, не составляют проблем. Но у хостера может быть свое мнение относительно подобной нагрузки.

Прежде чем менять тариф, для начала как минимум настроить mysql, ибо почти никогда его не настраивают, и уж тем более под свои нужды, особенно на VPS

Советую просто взять один из дефолтный конфигов предложенных самим mysql, например, в дебиане они лежат тут: /usr/share/doc/mysql-server-5.1/examples/ - это по идее будет достаточно.

Или же запустить скрипт http://day32.com/MySQL/tuning-primer.sh из под рута, он проанализирует общую работу БД и укажет на узкие места с рекомендованными настройками.

гыы. а вы не задумывались почему ? потому что это зачастую не приводит к результату.

это не только мое мнение. вот цитата из безоговорочно любимой "оптимизаторами" mysql книжки

Индексы по этим полям есть?

Ага, по-любому лучше на сервере с 8 гигами оперативка сидеть с mysql который настроен кэшировать только 16 метров. Образно говоря.

По своему опыту скажу, однажды возникла проблема, сайт генерировал ответы дольше 10-30 секунд. Настроив mysql мне удалось оживить этот сайт, и сайтом снова можно было нормально пользоваться.

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

А так не пойдет?

<?

if(isset($_POST['message'])){

mysql_query("INSERT INTO dle_forum_topics_backup

SELECT * FROM dle_forum_topics LEFT JOIN dle_forum_forums ON dle_forum_topics.forum_id = dle_forum_forums.id WHERE dle_forum_forums.access_read regexp '[[:<:]](5)[[:>:]]' GROUP BY last_date DESC LIMIT 10");

// Ну и вытаскивайте потом что надо из dle_forum_topics_backup для того кто только что оставил сообщение

}else{

// а если зашел просто зритель или бот, вы ему готовое и отсортированное выдали

$data = mysql_query("SELECT * FROM dle_forum_topics_backup");

}

?>

ну а что эти 8 гб просто так простаивают ? разница между кешем ОС и кешем mysql не такая большая, чтобы быть решающей.

Посмотрим, что напишет ТС про ваш оптимизатор настроек.

ТС, ничего не напишет, он дуб дубом)

Может быть, знать бы куда это.

Он ошибку выдал:

Error: Command line calculator 'bc' not found!

Вот после того как добавил индекс dle_forum_topics forum_id этот запрос перестал записываться в лог. А в другой таблице был видимо уже индекс PRIMARY, когда id добавил он внизу красным ругаться начал, что PRIMARY и id совпадают.

Может и вообще не в этом дело конечно.

Всем всем огромное спасибо!

Если не знаете то переведу на русский :)

Все дело в том что многие CMS движки настроены на производительные серверы. Я оставил вариант предложенный этим движком в первоначальном виде, а результат сохранил в отдельную таблицу. Это же самое что проставить индексы в таблице, только в десятки-сотни раз быстрее будет ответ.

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