К слову, сборка ShopModxBox поставляется сразу с настроенными индексами ;) Вот тут я немного слукавил:) На своих конечных сайтах, где нагрузка повыше, я создаю эти индексы. А вот в сборку не получается их запилить, так как мы не включаем в нее само ядро MODX-а. То есть при установке MODX-а создаются его родные индексы, и наши дополнительные в него не могут быть включены. Подумаю на счет того, чтобы все-таки подготовить и отправить PR в ядро с поправленной структурой и индексами.

В других таблицах (кроме modTemplateVarResource) тоже нужные индексы отсутствуют? Да, есть места. Была когда-то статья, в которой я подробно расписывал в каких колонках чего не хватает, но это было очень давно и сейчас этой статьи в паблике нет. Но планирую ее восстановить.

Я имел ввиду не xpdo-объекты, а объекты modx. Т.е. при работе с объектами modx из составных индексов нужен только tv_cnt (tmplvarid — contentid). При выборке значений TV там сначала создаётся объект TV, затем для него отбираются значения для нужных ресурсов — здесь как раз и используется индекс tv_cnt (tmplvarid — contentid). Мы как на разных языках говорим… Не говорите о MODX в вопросах работы с БД. Если мы разбираем базу данных и работу с ней, MODX-а вообще не следует касаться. Вопрос такой: почему при явном указании того же самого индекса запрос работает существенно быстрее. Не чуть быстрее, а существенно быстрее. А ведь запросов при загрузке веб-страницы выполняется куча. И все они могли бы работать гораздо быстрее… Вы внимательней на свой запрос посмотрите, на этот: SELECT DISTINCT modTemplateVarResource.contentid AS id FROM modx_site_tmplvar_contentvalues AS modTemplateVarResource WHERE (modTemplateVarResource.tmplvarid = 195) AND (modTemplateVarResource.value IN ('11326','19495','12813','20181','12693','12993','11327')) У вас выборка не по колонкам tmplvarid и contentid, а по tmplvarid и value. Для колонки value изначально нет индекса в MODX, потому и запрос с условием на эту колонку тормозит. Когда вы создали индекс idx_value_tv ( value ( 20 ), tmplvarid ) и использовали его в запросе, логично, что запрос полетел лучше. Даже если не используется индекс на колонку tmplvarid, запрос по числовым полям в любом случае идет лучше, чем по текстовым, тем более с плавающей длиной.

Это все равно никакого отношения к xPDO не имеет :)

Все гораздо проще — это элементарный недосмотр. Повторяюсь: xPDO — это не база данных и даже не тонкий клиент, это просто средство формирования запросов со своими надстройками. Я имел ввиду не xpdo-объекты, а объекты modx. Т.е. при работе с объектами modx из составных индексов нужен только tv_cnt (tmplvarid — contentid). При выборке значений TV там сначала создаётся объект TV, затем для него отбираются значения для нужных ресурсов — здесь как раз и используется индекс tv_cnt (tmplvarid — contentid). К слову, сборка ShopModxBox поставляется сразу с настроенными индексами ;) В других таблицах (кроме modTemplateVarResource) тоже нужные индексы отсутствуют? И вот этот вопрос остаётся в силе: Вопрос такой: почему при явном указании того же самого индекса запрос работает существенно быстрее. Не чуть быстрее, а существенно быстрее. А ведь запросов при загрузке веб-страницы выполняется куча. И все они могли бы работать гораздо быстрее…

Если подусловие modTemplateVarResource.tmplvarid = 195 усложнить: modTemplateVarResource.tmplvarid IN (195,196) то MySQL по умолчанию выбирает уже другой индекс — idx_value. При этом явное указание этого же индекса ускоряет запрос в 3 раза. В обоих случаях — tmplvarid = 195 и tmplvarid IN (195,196) индекс idx_value является самым быстрым

Это допдействия. Они решают, но и без этого не должно такой проблемы возникать. То есть я все-таки это отнесу к багам MODX-а.

Почему, в таблице (modTemplateVarResource) изначально нет нужных индексов, задавать не буду — судя по всему, при работе в modx исключительно на уровне xpdo-объектов другие индексы (кроме тех, что имеются «в коробке»), и не нужны. На счет возможной ненужности — в корне не правильное предположение. Все гораздо проще — это элементарный недосмотр. Повторяюсь: xPDO — это не база данных и даже не тонкий клиент, это просто средство формирования запросов со своими надстройками. Никакие собственные индексы он не умеет строить, использовать и т.п. Это все на совести базы данных. А индексы правильные не настроены — это не единственная проблема. Элементарно — в разных таблицах в связанных полях не совпадают типы данных. К примеру в одной таблице id int(10)unsigned, а в другой таблице связанная колонка int(11) (не unsigned). В этом плане в MODX действительно недосмотр большой. К слову, сборка ShopModxBox поставляется сразу с настроенными индексами ;) И еще большая такая проблема в xPDO — отсутствует поддержка innoDB и транзакций. Сам Джейсон Ковард выражает свое неуважение к этим механизмам, типа они переоценены и не нужны. При этом в xPDO в этом плане большая проблема есть — двойное сохранение связанных объектов, и в случае использования вторичных ключей и транзакций, мы просто получим кучу сообщений об ошибках и сломанную логику. Но мы с Сергеем Прохоровым имеем в этом направлении серьезные наработки и исследования, так что с большой долей вероятности скоро отправим PR, который решает эти проблемы и позволит использовать транзакции. В больших проектах без транзакций просто никак. Когда у вас за раз сохраняется пара десятков связанных объектов, вы замахаетесь отлавливать ошибки и корректные откаты формировать без транзакций.

Возьмём простой запрос на выборку идентификаторов ресурсов из таблицы (modTemplateVarResource): SELECT DISTINCT modTemplateVarResource.contentid AS id FROM modx_site_tmplvar_contentvalues AS modTemplateVarResource WHERE (modTemplateVarResource.tmplvarid = 195) AND (modTemplateVarResource.value IN ('11326','19495','12813','20181','12693','12993','11327')) Запрос выполняется 0.0151 сек План запроса: id select_type table type possible_keys key key_len ref rows Extra 1 SIMPLE modTemplateVarResource ref tmplvarid,tv_cnt tv_cnt 4 const 6156 Using where Далее добавляем в таблицу (modTemplateVarResource) 4 отсутствующих индекса: ALTER TABLE modx_site_tmplvar_contentvalues ADD INDEX idx_value ( value ( 20 ) ) ALTER TABLE modx_site_tmplvar_contentvalues ADD INDEX idx_tv_value ( tmplvarid , value ( 20 ) ) ALTER TABLE modx_site_tmplvar_contentvalues ADD INDEX idx_value_tv ( value ( 20 ), tmplvarid ) ALTER TABLE modx_site_tmplvar_contentvalues ADD INDEX idx_content_tv ( content, tmplvarid ) Индекс (tv — content) изначально уже имеется (tv_cnt) Снова запускаем тот же запрос: 0.0038 сек План запроса (используется индекс idx_value_tv): id select_type table type possible_keys key key_len ref rows Extra 1 SIMPLE modTemplateVarResource range tmplvarid,tv_cnt,idx_tv_value,idx_value_tv idx_value_tv 66 NULL 60 Using where; Using temporary Далее непосредственно указываем серверу использовать индекс idx_value_tv: SELECT DISTINCT modTemplateVarResource.contentid AS id FROM modx_site_tmplvar_contentvalues AS modTemplateVarResource USE INDEX (idx_value_tv) WHERE (modTemplateVarResource.tmplvarid = 195) AND (modTemplateVarResource.value IN ('11326','19495','12813','20181','12693','12993','11327')) Получаем: 0.0027 сек. При этом план запроса тот же самый: id select_type table type possible_keys key key_len ref rows Extra 1 SIMPLE modTemplateVarResource range idx_value_tv idx_value_tv 66 NULL 60 Using where; Using temporary =============== Почему, в таблице (modTemplateVarResource) изначально нет нужных индексов, задавать не буду — судя по всему, при работе в modx исключительно на уровне xpdo-объектов другие индексы (кроме тех, что имеются «в коробке»), и не нужны. Вопрос такой: почему при явном указании того же самого индекса запрос работает существенно быстрее. Не чуть быстрее, а существенно быстрее. А ведь запросов при загрузке веб-страницы выполняется куча. И все они могли бы работать гораздо быстрее… P.S. Если выборку выполнять из таблицы ресурсов, а tv подключать через JOIN и фильтровать так, как приведено здесь (запросы составляются на уровне xpdo, но чистый SQL получается таким как в сабже), то получаем полностью идентичные планы запросов (в части сабжевой фильтрации) и полностью идентичные наблюдения со скоростью их выполнения. На реальных запросах скорость выполнения ощутима.

ага, оно!