Задавайте вопросы, мы ответим
Вы не зашли.
Спрашивал об этом на многих англоязычных форумах, но никто не может ответить, как решить эту проблему. Может здесь есть умные люди...
Мне нужен следующий результат:
Неактивен
Теоретически должно хватать индекса на (profile_id, vtime), с ним точно
не работает? Можете показать полные структуры табличек, чтобы можно
было поиграть с ними?
Кстати, в Вашем запросе табличка с сессиями совсем лишняя — объединение
с ней левое (а значит количество строк не ограничивается), в списке
полей и в WHERE она не участвует. Поэтому ее можно смело выкинуть в
тартарары
Неактивен
Спасибо за Ваш ответ.
Таблица с сессиями не лишняя - в ней проверяется он-лайн ли пользователи на данный момент, которые находятся в stats_profileviewers.
У меня похожих ситуаций, где вовлечены 3 таблицы (usertable+portalsession+еще 1 таблица), много, поэтому очень важно найти оптимальное решение.
Таблицы:
Отредактированно lpa (19.08.2009 13:12:08)
Неактивен
Это все LEFT JOIN виноват Отношение «может быть, а может не быть» не позволяет
так легко бегать по ключу, как это происходит с обычным JOIN. Впрочем, 200 строк
особой роли не играют.
Неактивен
В этом примере 200 строк, но есть и тысячи, при том их количество увеличивается.
Похоже, что никто не знает способа, как решить проблему в моих примерах. Даже не знаю, что лучше - оставить все, как есть - с FILESORT или делать, как в моем первом сообщении:
Неактивен
Ну, я по прежнему придерживаюсь мнения, что нужно попробовать добавить
ключик на (profile_id, vtime) и выбросить ненужную таблицу с левым объединением
Неактивен
Если я выброшу таблицу portalsession, то в результатах не смогу показать, которые пользователи он-лайн, а это важно.
Неактивен
Ну, тем не менее, в текущем запросе она не участвует даже если присутствует.
Но все равно индекс стоит создать, даже если Вы мне не верите по поводу таблицы
Неактивен
Создал индекс на (profile_id, vtime). Убрал 3 таблицу. Вот, что получилось:
Неактивен
Ну, крышу ему во втором случае сносит, потому что в одной таблице у Вас INT,
а во второй — VARCHAR. Из-за этого он их пытется сравнить «в смысле строк» —
вытащить оба значения и попытаться понять — однаковые они или нет, пытаясь
преобразовать одно к другому. Что приводит к полному сканированию таблички
и всем остальным неприятным последствиям.
К слову сказать, если я правильно Вас понял, то Вы хотите, чтобы в этом же
запросе появлялся флажок «есть ли строчки, соответствующие этому пользователю,
в таблице portalsession». После того, как поменяете тип данных, его стоит добавить
третьей табличкой (так, как Вы делали, но выводя нужную информацию):
Неактивен
Ой, точно - во второй таблице VARCHAR. Я совсем упустил этот факт. Большое спасибо Вам - попробую поменять.
Неактивен