|
|
|
| В логах slowquery MYSQL
фигурирует одни запрос
SELECT
COUNT(*) AS c,
t.title,
t.uri,
n.number,
(SELECT cats.`uri` FROM `categories` AS cats,`texts_categories` AS tc WHERE tc.`text_id`=t.`id` AND tc.`cat_id`=cats.`id` LIMIT 1) AS c_uri
FROM
`texts` AS t
INNER JOIN `texts_views` AS tv ON tv.`text_id` = t.`id`
INNER JOIN `numbers` AS n ON n.`id`=t.`number_id`
WHERE
TO_DAYS(NOW())-TO_DAYS(tv.`date`) <=7
AND t.`status`>0
AND n.`section`='vladnews'
GROUP BY t.`id`
ORDER BY c DESC
LIMIT 20
|
Есть методы опмизации его | |
|
|
|
|
|
|
|
для: VL
(15.10.2009 в 08:40)
| | Надо полагать, Вы не его автор.
Лучший способ оптимизировать такой запрос - написать заново, предварительно выкинув.
Следующий - отдать автору.
Потому как запрос крайне грязный (приличный сервер СУБД счел бы его ошибочным) | |
|
|
|
|
|
|
|
для: Trianon
(15.10.2009 в 08:51)
| | Отдать автору, автора уже в другом месте заседает)
Так как админ человек универсальный в офисе)
То просто порой нету и 5 минут подумать.
Вот и спросил помощи.
Ну тогда на досуге подумаю. | |
|
|
|
|
|
|
|
для: VL
(15.10.2009 в 09:26)
| | Подумать можно над задачей. Задачу Вы не поставили.
А исправлять запрос имеет смысл если он без ошибок, просто медленный. | |
|
|
|
|
|
|
|
для: Trianon
(15.10.2009 в 10:13)
| | >А исправлять запрос имеет смысл если он без ошибок, просто медленный.
Собственно, как я понял, об этом речь и идет
>В логах slowquery MYSQL | |
|
|
|
|
|
|
|
для: cheops
(15.10.2009 в 16:25)
| | Игорь, это медленный ошибочный запрос :)
если поля t.title, t.uri, n.number хоть както определяются группирующим полем t.id
то n.number и уж тем более весь c_uri - ну никак.
LIMIT 1 во вложенном запросе - вообще песня.
Можно убрать c_uri за агрегат.
Если таблица numbers - полная б её тоже можно туда убрать.
Можно упростить условие недельной даты так, чтоб сервер спокойно мог воспользоваться индексом.
Но если написать запрос с нуля (зная схему БД) то, очевидно, распутывать все эти хитросплетения просто не возникнет нужды. | |
|
|
|