Подождём что скажет ТС. Если проверка, которую я указал выше разгрузит базу, то причина в RAND() .
Я не отрицаю, что проблема в текстовых полях, но RAND() здесь играет не последнюю роль. Если я ошибаюсь, готов признать свою вину. Всегда готов учится. :) То, что в идеале нужна нормализация базы - согласен - эта мысль мне тоже вначале приходила. Но возможно можно исправить проблему меньшими силами.
update: сейчас подумал, что проверка не определит проблема больше в rand или вообще в сортировке по текстовым полям.
Слава Шевцов: Так что вряд ли тут что-то можно править. Но Вы правы - проблемы из-за этих сортировок.
Можно исправить способ случайного "доставания" записей. Если не критично количество запросов, то можно доставать по COUNT(*) (что при присутствиии индексов по id будет малозатратно), затем генерировать $rand = rand(0, $row['count']) и делать N-ое количество запросов "SELECT .... LIMIT $rand, 1".
Для 25+25 записей это конечно может быть "что занадто, то не здраво", но можно подумать и о оптимизации алгоритма.
вот эта строка может добавлять " AND category_id IN ($selected_categories)" проблем, но в случае если категорий много.
Опять же без структуры базы сказать что-то трудно. Скорее всего проблема в неправильно проставленных (или точнее недоставленных) индексах, ибо запросы не очень сложные.
IP делал редирект на страницу со множеством внешних ссылок
Я думаю как вариант можно в контент добавлять ссылки на себя (это если знать, что ТС не вырезает ссылки). :)
Проблема не в RAND()
Подождём что скажет ТС. Если проверка, которую я указал выше разгрузит базу, то причина в RAND() .
Я не отрицаю, что проблема в текстовых полях, но RAND() здесь играет не последнюю роль. Если я ошибаюсь, готов признать свою вину. Всегда готов учится. :) То, что в идеале нужна нормализация базы - согласен - эта мысль мне тоже вначале приходила. Но возможно можно исправить проблему меньшими силами.
update: сейчас подумал, что проверка не определит проблема больше в rand или вообще в сортировке по текстовым полям.
Так что вряд ли тут что-то можно править. Но Вы правы - проблемы из-за этих сортировок.
Можно исправить способ случайного "доставания" записей. Если не критично количество запросов, то можно доставать по COUNT(*) (что при присутствиии индексов по id будет малозатратно), затем генерировать $rand = rand(0, $row['count']) и делать N-ое количество запросов "SELECT .... LIMIT $rand, 1".
Для 25+25 записей это конечно может быть "что занадто, то не здраво", но можно подумать и о оптимизации алгоритма.
Слава Шевцов,
мне кажется основная проблема в
и
Ну и для левой колонки аналогично.
Два запроса с такими участками для нормальной базы могут превосходно её положить :)
KosoyRoman,
попробуйте поменять
строку в файле config.php
на
и строку
на
Если скорость возрастёт значительно - значит проблема была в случайной сортировке (испытывать на реальной базе!).
Для начала поставьте индекс на поле article_cat в таблице pqdb_articles
Если не поможет будем смотреть дальше.
Update: Мой совет нужен, но проблема не в этом. Частично прав Слава Шевцов - там идёт сортировка по RAND() , что и приводит к тормозам.
присоединюсь к телепатам. :)
вот эта строка может добавлять " AND category_id IN ($selected_categories)" проблем, но в случае если категорий много.
Опять же без структуры базы сказать что-то трудно. Скорее всего проблема в неправильно проставленных (или точнее недоставленных) индексах, ибо запросы не очень сложные.
<html>
<head>
<script>
function AdLoad(){
document.getElementById('adv').innerHTML = 'тут собсно реклама';
}
</script>
</head>
<body onLoad="adLoad()">
<div id="adv">Загрузка рекламных объявлений...</div>
</body>
</html>
Что-то типа этого.
Скажите владельцу, мол разблокируйте, я тут попарсю....
Если не поможет, то http://browsershots.org/ и через FineReader :D
Переезжать, так это не просто... у меня там штук десять сайтов.
Я долго собирался, но всё же съехал. :)
А фрю кто-то продает?
Apple под названием Mac OS X :)