Тормозит "Просмотр сообщений пользователя" при включенной премодерации

[Slavegirl]

Здравствуйте!

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

http://www.simplemachines.ru/index.php?action=profile;area=showposts;u=16266

список этих сообщений формируется с заметными тормозами. Исключением является, если список сообщений просматривает администратор форума - для него тормозов нет.

Причина кроется в следующих запросах к базе данных:

Profile-View.php

Код Выделить Развернуть


$request = $smcFunc['db_query']('', '
SELECT COUNT(*)
FROM {db_prefix}messages AS m' . ($user_info['query_see_board'] == '1=1' ? '' : '
INNER JOIN {db_prefix}boards AS b ON (b.id_board = m.id_board AND {query_see_board})') . '
WHERE m.id_member = {int:current_member}' . (!empty($context['boards']) ? '
AND m.id_board IN ({array_int:boards})' : '') . (!$modSettings['postmod_active'] || $context['user']['is_owner'] ? '' : '
AND m.approved = {int:is_approved}'),
array(
'current_member' => $memID,
'is_approved' => 1,
'boards' => $context['boards'],
)
);


а именно при выполнении условия !$modSettings['postmod_active'] || $context['user']['is_owner'].

На форуме присутствует большое число пользователей с количеством сообщений > 1000, просматривать полный список этих сообщений для остальных пользователей слишком дискомфортно.

Хочу спросить, может в базе данных не хватает какого-нибудь дополнительного индекса, чтобы подобные запросы выполнялись быстрее? Например, меня очень смущает индекс под названием "Approved" в таблице "smf_messages". Может в него добавить еще какие-нибудь поля для комбинированного индексирования?

Заранее большое спасибо за советы!

[digger®]

Не должно это добавлять каких-то ощутимых тормозов.
Субъективно - смотрю сообщения пользователя с 10000 сообщений, не ощущаю никакого замедления (на обычном хостинге).

[Slavegirl]

digger, я верю, что не должно... Но при включении премодерации (сервер VDS) 10 тыс. сообщений пользователя у меня выводятся 20-30 секунд. Отключаю премодерацию - отображаются мгновенно. Видимо, ОЗУ слишком мало для таких запросов.

[digger®]

digger, я верю, что не должно... Но при включении премодерации (сервер VDS) 10 тыс. сообщений пользователя у меня выводятся 20-30 секунд. Отключаю премодерацию - отображаются мгновенно. Видимо, ОЗУ слишком мало для таких запросов.

А как вы определили что дело именно в этом условии и в этом запросе?

[Slavegirl]

Убирала проблемное условие в запросе. Без проверки на "одобрение сообщений" выборка работает без тормозов.

Тормоза как раз в этом запросе, который подсчитывает количество записей:

SELECT COUNT(*) ...

[digger®]

Попробуйте добавить в таблицу messages составной индекс по полям id_member,  id_board, approved, хотя, на мой взгляд, это излишне.

[Жека]

А индекс Approved перестраивали, помогает/нет?

[Slavegirl]

digger, спасибо, помогло! Добавила новый индекс с указанными полями, тормоза полностью пропали (даже на втором сервере со слабенькой VPS-кой)!
А если добавить эти же поля в уже имеющийся индекс "Approved", это тоже сработает? Также я не в курсе, влияет ли очередность полей в индексе на производительность данной задачи...

[digger®]

digger, спасибо, помогло! Добавила новый индекс с указанными полями, тормоза полностью пропали (даже на втором сервере со слабенькой VPS-кой)!
А если добавить эти же поля в уже имеющийся индекс "Approved", это тоже сработает? Также я не в курсе, влияет ли очередность полей в индексе на производительность данной задачи...

Оставьте отдельный индекс "Approved".
Очередность полей в индексе на производительность не влияет.

У вас таблица messages не InnoDB?

[Slavegirl]

digger, нет, не InnoDB (скриншот).

Только что обнаружила в списке индекс под названием "show_posts" (странно, что сразу его не заметила). Наверное, он как раз и создавался для поиска сообщений конкретного пользователя. Вместо создания отдельного комбинированного индекса вклеила туда поле "approved", и все тоже заработало, как надо (получилось то же самое).