Задавайте вопросы, мы ответим
Вы не зашли.
Какие можно добавить ключи, чтобы оптимизировать следующие два запроса:
SELECT blog_n . * , blog_r . *
FROM blog_n, blog_r
WHERE blog_n.id_r = blog_r.id_r
AND blog_n.flag =1
ORDER BY blog_n.id_n DESC
LIMIT 0 , 15;
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE blog_r ALL PRIMARY NULL NULL NULL 19 Using temporary; Using filesort
1 SIMPLE blog_n ref id_r id_r 1 fashiony.blog_r.id_r 360 Using where
SELECT blog_u.avatar, blog_c.comment, blog_c.id_u, blog_c.id_c, blog_c.name, blog_c.rating, blog_c.date_add, blog_n.id_n, blog_n.name_n, blog_n.comments, blog_n.login_c, blog_n.id_u_c, blog_r.id_r, blog_r.razdel FROM blog_c LEFT JOIN blog_n ON blog_c.id_n=blog_n.id_n LEFT JOIN blog_r ON blog_n.id_r=blog_r.id_r LEFT JOIN blog_u ON blog_c.id_u=blog_u.id_u ORDER BY blog_c.rating DESC, blog_c.date_add DESC LIMIT 169350, 50;
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE blog_c ALL NULL NULL NULL NULL 223395 Using filesort
1 SIMPLE blog_n eq_ref PRIMARY PRIMARY 4 fashiony.blog_c.id_n 1
1 SIMPLE blog_r eq_ref PRIMARY PRIMARY 1 fashiony.blog_n.id_r 1
1 SIMPLE blog_u eq_ref PRIMARY PRIMARY 4 fashiony.blog_c.id_u 1
Неактивен
Ну, очевидно, blog_n(flag, id_n), blog_r(id_r), blog_c(rating, date_add).
Неактивен
blog_r(id_r) такой ключ уже был, причем первичный уникальный авто инткремент.
===== Первый запрос =====
EXPLAIN SELECT blog_n. * , blog_r. *
FROM blog_n, blog_r
WHERE blog_n.id_r = blog_r.id_r
AND blog_n.flag =1
ORDER BY blog_n.id_n DESC
LIMIT 0 , 15;
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE blog_r ALL PRIMARY NULL NULL NULL 19 Using temporary; Using filesort
1 SIMPLE blog_n ref id_r id_r 1 fashiony.blog_r.id_r 360 Using where
После ALTER TABLE `blog_n` ADD INDEX ( `flag`, `id_n` ) ;
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE blog_n ref id_r,flag flag 1 const 6766 Using where
1 SIMPLE blog_r eq_ref PRIMARY PRIMARY 1 fashiony.blog_n.id_r 1
Не хуже ли стало? В колонке rows почему-то теперь затронуто 6766 и 1, а было 19 и 360.
===== Второй запрос:========
ALTER TABLE `blog_c` ADD INDEX ( `rating`, `date_add` ) ;
SELECT blog_u.avatar, blog_c.comment, blog_c.id_u, blog_c.id_c, blog_c.name, blog_c.rating, blog_c.date_add, blog_n.id_n, blog_n.name_n, blog_n.comments, blog_n.login_c, blog_n.id_u_c, blog_r.id_r, blog_r.razdel
FROM blog_c
LEFT JOIN blog_n ON blog_c.id_n = blog_n.id_n
LEFT JOIN blog_r ON blog_n.id_r = blog_r.id_r
LEFT JOIN blog_u ON blog_c.id_u = blog_u.id_u
ORDER BY blog_c.rating DESC , blog_c.date_add DESC
LIMIT 169350 , 50;
Всё тоже самое:
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE blog_c index NULL rating 11 NULL 223455
1 SIMPLE blog_n eq_ref PRIMARY PRIMARY 4 fashiony.blog_c.id_n 1
1 SIMPLE blog_r eq_ref PRIMARY PRIMARY 1 fashiony.blog_n.id_r 1
1 SIMPLE blog_u eq_ref PRIMARY PRIMARY 4 fashiony.blog_c.id_u 1
Неактивен
Нет, не стало. Перемножьте, чтобы убедиться в этом Учтите, что теперь
у Вас сортировка идет из индекса, поэтому реально вытащатся 15 строк,
а не 7к.
===
Аналогично.
Неактивен
paulus написал:
Ну, очевидно, blog_n(flag, id_n)
А не наоборот ли, blog_n(id_n,flag)? Особенно если flag - это какой нибудь флажок 0 или 1. Полученный explain какой то странный... я б еще ANALYZE TABLE сделал
И как он будет сортировать по индексу, если id_n - в конце индекса
Отредактированно Shopen (26.06.2010 02:38:15)
Неактивен
Даже если flag — битовое поле, сначала в WHERE пройдет оно, а потом
только будет сортировка, поэтому индекс нужен, разумеется, в этом порядке.
Неактивен