Кто-то из великих педагогов сказал, что проблем с вос­питанием детей было бы гораздо меньше, если бы взрослые помнили о том, что сами когда-то были ма­ленькими..


Теперь у меня уже подрастает
" Большинство родителей бывают обескуражены тем,

В детстве у меня под кроватью "жил" говорящий жу­равленок Егорка, который повредил ногу и отбился от стаи..


На­пример, восьмилетний Петя, спокойный
Но когда ложь становится привычкой,

Ночами напролет мы разговаривали с ним о дале­ких жарких странах, а по утрам, как неопровержимое доказательство существования Егорки, я находила под кроватью белые перышки...
Никакие доводы родителей о том, что белых журавлей не бывает, а перья и пух вы­пали из подушки, не могли разрушить мою сказку..


Ложь-защита.
И не возвращаться больше

Есть маленький вопрос:

включил модуль devel (советую всем - узнаете много интересного) что-бы посмотреть как можно друпал ускорить и нашел везде непонятный несложный запрос который выполняется раз в 20 медленнее чем другие, при чем все поля которые есть - поодиночке уже проиндексированы:

SELECT DISTINCT(n.nid), n.sticky, n.title, n.created FROM node n INNER JOIN term_node tn ON n.nid = tn.nid WHERE tn.tid IN (80) AND n.status = 1 ORDER BY n.sticky DESC, n.created DESC LIMIT 0, 10

Вопрос - какие поля таблиц надо проиндексировать что-бы он выполнялся быстрее?

и еще - в таблице локализации - тип поля бинарный - а его нельзя проиндексировать - вопрос - зачем его не сделали "fulltext" что-бы проиндексировать так как эапрос с ним выполняется раз в 50 медленнее чем другие.

Ps: попутно заметил что в таблице node_revision не проиндексировано поле vid, а в таблице cache поле cid - если их проиндексировать, то общая скорость друпала у меня возрастает раза в 2-4 и более.


Можно

Можно попросить mysql объяснить, какие он выбирает индексы для запроса. Если запустить следующую команду, то многое станет очевидным:

EXPLAIN SELECT DISTINCT(n.nid), n.sticky, n.title, n.created FROM node n INNER JOIN term_node tn ON n.nid = tn.nid WHERE tn.tid IN (80) AND n.status = 1 ORDER BY n.sticky DESC, n.created DESC LIMIT 0, 10

Бинарный тип поля тоже можно проиндексировать, только нужно указать размер индексируемой части поля: create index locales_source_source on locales_source (source(64));

aslw – 13 March, 2006 – 11:13

*

получил вот такой ответ

id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE tn ref nid,tid tid 4 const 292 Using temporary; Using filesort
1 SIMPLE n eq_ref PRIMARY,status,node_status_type PRIMARY 4 orthodoxy_newsnews.tn.nid 1 Using where

а что дальше с ним делать?

PS интересно что когда убираю ORDER BY n.sticky DESC, n.created DESC - то все нормально - выполняется в 100 раз быстрее, однако поля sticky created проиндексированы как INDEX , что можно еще придумать?

drupal.kiev1 – 13 March, 2006 – 13:13

Re: *

[quote=drupal.kiev1]получил вот такой ответ

id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE tn ref nid,tid tid 4 const 292 Using temporary; Using filesort
1 SIMPLE n eq_ref PRIMARY,status,node_status_type PRIMARY 4 orthodoxy_newsnews.tn.nid 1 Using where

а что дальше с ним делать?
[/quote]
Это только дает некоторую наглядность. По-моему запрос оптимизирован. Для первой таблицы используюется индекс "tid", для второй - primary key.
Еще можно попробовать избавиться от DISTINCT, по-моему он там лишний, а ресурсов требует столько же, сколько требует группировка.

aslw – 13 March, 2006 – 16:20

хроново оптимизирован

можно и получше
самая хреновая сторчка здесь
1 SIMPLE tn ref nid,tid tid 4 const 292 Using temporary; Using filesort

Using filesort и тормозит весь процесс рар в 20

тебе нужно проиндексировать поля по которым ты сортируеш
ORDER BY n.sticky DESC, n.created DESC

а если будеш сортировать только по одному полю избавишся и от Using temporary (еще раза в 3 быстрее) тогда у тебя запрос летать будет

PS: хотя на 292*4 записях ето не особо критично
PPS: а еси-бы я етот пост год назад заметил :)

_dimas_ – 4 May, 2007 – 15:50