Медленные запросы к базе

не слышал про то что они тяжелые если раставить правильно индексы, ну и еще пару полезных мелочей при оптимизации сделать: типо выборка тех полей который нужны,

ну как говорится — флаг вам в руки , помогите нам, оптимизируйте запросы.

ну как говорится — флаг вам в руки, помогите нам, оптимизируйте запросы.

no problem.

код запроса(ов)
EXPLAIN
и результаты профилирования в студию:)

ну или как вариант дайте дамп таблиц которые используются в запросе и сам(и) запрос(ы)

вот такие например
SELECT p.pubdate, p.id as post_id,
u.id as uid, u.nickname as author,
u.login as author_login,
t.title as threadtitle, t.id as threadid
FROM cms_forum_posts p FORCE INDEX (uthr)
LEFT JOIN cms_forum_threads t USE INDEX (fi) ON t.id = p.thread_id AND t.is_hidden=0
INNER JOIN cms_forums f USE INDEX (NSRP) ON f.id = t.forum_id
LEFT JOIN cms_users u ON u.id = p.user_id
WHERE (f.NSLeft >= 2 AND f.NSRight <= 7)
ORDER BY p.id DESC
LIMIT 1

SELECT con.*, con.id as slid, con.pubdate as fdate, u.nickname as author, u.login as author_login
FROM cms_content con
LEFT JOIN cms_category cat ON cat.id = con.category_id
LEFT JOIN cms_users u ON u.id = con.user_id
WHERE con.published = 1 AND con.showlatest = 1 AND con.category_id = 21
AND (con.is_end=0 OR (con.is_end=1 AND con.enddate >= '2012-09-06 23:29:38' AND con.pubdate <= '2012-09-06 23:29:38'))
ORDER BY con.id DESC LIMIT 6

SELECT *, m.id as mid, m.template as tpl
FROM cms_modules m, cms_modules_bind mb
WHERE (mb.position = 'foo_banner') AND
m.published = 1 AND
m.id = mb.module_id AND
(mb.menu_id = '38' OR mb.menu_id = 0)

ORDER BY m.ordering ASC

SELECT *, m.id as mid, m.template as tpl
FROM cms_modules m, cms_modules_bind mb
WHERE (mb.position = 'main_menu') AND
m.published = 1 AND
m.id = mb.module_id AND
(mb.menu_id = '21' OR mb.menu_id = 0)

ORDER BY m.ordering ASC

код запроса(ов)
EXPLAIN
и результаты профилирования в студию:)

тяжело судить по одному запросу😊кинь хотя бы структуру таблиц, если не можешь профилирование и explain(ну или дамп если есть возможность.)

В нашей темке активность😊это хорошо

EXPLAIN SELECT p.pubdate, p.id AS post_id, u.id AS uid, u.nickname AS author, u.login AS author_login, t.title AS threadtitle, t.id AS threadid
FROM cms_forum_posts p
FORCE INDEX ( uthr )
LEFT JOIN cms_forum_threads t
USE INDEX ( fi ) ON t.id = p.thread_id
AND t.is_hidden =0
INNER JOIN cms_forums f
USE INDEX ( NSRP ) ON f.id = t.forum_id
LEFT JOIN cms_users u ON u.id = p.user_id
WHERE (
f.NSLeft >=2
AND f.NSRight <=7
)
ORDER BY p.id DESC
LIMIT 1

id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE f range NSRP NSRP 4 NULL 4 Using where; Using temporary; Using filesort
1 SIMPLE t ref fi fi 8 eolegnn_nnonline.f.id,const 2627 Using where
1 SIMPLE p ref uthr uthr 4 eolegnn_nnonline.t.id 1
1 SIMPLE u eq_ref PRIMARY PRIMARY 4 eolegnn_nnonline.p.user_id 1

это пока все что могу сейчас, вечером таблицы сброшу, но они есть в пакете инсталляционном

ну так суть не в пакете инсталяционном а дапе базы ибо по вашему експлену стоит выборка условная которая на запись основной выборки возвращает 2627 записей. Чтобы повторить ваш запрос нужно иметь аналогичный объем данных.

Чтобы повторить ваш запрос нужно иметь аналогичный объем данных.

Так и не нужно воспроизводить, нужно посмотреть взлягодом программиста и сказать:
— Здесь все отлично с запросом, ничего не улучшишь
— Этото запрос можно сделать так и так

пардон, не было возможности и времени зайти на форум. Как вариант можно использовать покрывающий индекс(включая покрытие условий сортировки). ну еще можно оптимизировать структуру полей БД. Так же заметил случайно в одном из тех запросов что вы писали используется какой то индекс, которого в "стандартно" сборке нету. Извините я не пророк, так что хотя бы в следующий разы присылайте код создания таблиц(ы) :)

используется какой то индекс

Это я добавил сам.