129сказали спасибоУвы, допилить многостраничные простыни составных запросов из десятка таблиц не представляется реально возможным. Всё красиво и быстро на тестовом сервере. А проблемы начинаются после миллиона постов.
Поиск
Увы, допилить многостраничные простыни составных запросов из десятка таблиц не представляется реально возможным. Всё красиво и быстро на тестовом сервере. А проблемы начинаются после миллиона постов.
Ну главное понять логику работы, количество строк в запросе не самый важный критерий, да и всегда можно поделить на части и последовательно найти узкое место.
Миллион постов - это общее количество на форуме?Сообщение от admin
Если в коротких темах работает все быстро, значит индекс по ID темы отрабатывает нормально, далее я вижу пока только условие по номеру поста, ибо больше вроде не меняются условия, возможно надо повесить составной индекс на поля, в которых хранится ID темы и номер поста, если это не помогает - только смотреть запросы, который выбирает данные для построения страницы треда.
Резать большие темы это конечно выход, но имхо очень костыльный.
Запросик-то простой. Прежде чем вывести заданную страницу темы, нужно получить список всех видимых постов. Ошибка изначально была в архитектуре. Поэтому дыру в голове не заткнешь, индексы не построишь и запрос не перепишешь.
SELECT post.postid, post.visible, post.userid, post.attach
FROM post AS post
WHERE post.threadid = 35
AND post.visible IN (1
,2
,0
)
OR (post.threadid = 35 AND post.visible=0 AND post.userid="1")
ORDER BY post.dateline
Это только у меня теперь на форуме постоянные попытки кражи информации (вряд ли)? Или вы просто не в курсе этого? Неужели придется бросать форум?
Пока не думаю что много, если ерунду какую, еще как заметил принял меры, но приятного мало.
Последний раз редактировалось Vic278; 18.01.2013 в 22:58.
Вить, че у тя опять сперли?!
Во-первых запрос немного криво написан, я бы так сделал:
Возникают вопросы:SELECT post.postid, post.visible, post.userid, post.attach
FROM post AS post
WHERE post.threadid = 35
AND (post.visible between 0 and 2
OR post.userid=1)
ORDER BY post.dateline
первый:
почему три состояния видимости? 0, я так понял это если пост подработал модератор, 1 - пост отоброжается, а что такое 2?post.visible IN (1
,2
,0
)
второй:
где пейджинг?
третий:
юзер и ид=1 это видимо сам админ, типа условие построено так, чтобы нельзя было скрыть Его постыpost.userid="1". Оно конечно хардкодить нехорошо, но смущает меня не то. А смущает другое: в этом запросе индексы по полю userid работать не будут, ибо выполняется неявное преобразование типов, будет тупо сиквенс скан.
Что за программа, что крадут и с какого адреса?
- - - Добавлено - - -
AKWoland, userid текущего пользователя. Индексы работают. В целом база недостаточно денормализована + недальновидность архитектора. Может быть и не в этом конкретном запросе дело, запамятовал я. Но когда несколько групп пользователей использует несколько тем в качестве чата, то нагрузка становится заметной.
Не, если переменная строковая, то по идее он будет для каждой строки каст делать, хотя я не так много с мускулем имел дело, но MS SQL делает именно так.
Надо будет на выходных развернуть этот движок на тестовом хостинге и покопаться. Чисто ради профессионального интереса
С любого меняющегося IP, папки и др. защищенную инфу при входе и после этого на разных браузерах. При загрузке каждой стр. форума до 2 разных категорий.
- - - Добавлено - - -
С любого меняющегося IP, эл. почту, папки и др. защищенную инфу при входе и после этого на разных браузерах. При загрузке каждой стр. форума до 2 разных категорий.
У меня никакой подозрительной активности не наблюдается.
Обычно когда сайт взламывают и размещают вредоносный код, файрфукс и яндекс начинают сильно материться, тут такого нет.
Я как-то сайтец делал одной конторке, позвонили и плевались слюнями что типа на сайте вирусня. Оказалось, что их шеф будучи с админскими правами был не в силах запомнить нормальный пароль и поменял его на "123456", соответственно кто-то это дело подобрал и внедрил в шаблон какое-то говнецо.
Ваши права
