Могли бы. Но не привели бы. Ибо лень-матушка.
Если бы я не пришел, то ничего бы мне не было. По прописке я не живу. Имею право.
Юридически вторая квартира особо со мной не связана. Найти не сложно, но надо напрягаться. Зачем? У меня было несколько дел в которых реально было за что зацепиться и крутить нервы. Закончились классически:
Я пошел чисто потому что дело связано с юриком, да еще и у юрика юрадрес совпадает с моим адресом прописки, да еще и юрика этого как по заказу я вот только сейчас начал выводить из спячки, причем не просто выводить, а он участвует в тендере (или как там оно, когда выбирают покупателей а не продавцов? конкурс?) в фонде гос.имущества, и еще пару договоров которые сложно переписывать. Реально мне грозил "девятый стан" (не помню как стан перевести... состояние?), это когда налоговая в реестре отмечает что предприятие не находится по своему юрадресу. Снимается за день, письмом (если за ним не стоит претензия от налоговой милиции, а она не стоит). Но надо же будет везде появиться и отсветиться... В общем проще идти и бодаться в УБЕП области.
Вот честно. "Кто не спрятался, я не виноват" - главный принцип всех ментов. А кто спрятался, того лень искать.
Могут. Но это геморрой. А если дело не про ловлю покемонов или другое государственной важности, и на нем не заработать, то нафиг напрягаться?
Терпилу твоего могут привести? Могут. Приведут? Неа.
Я тоже обычно не хожу. Да и всучить мне повестку обычно еще тот квест. Но тут дело касается живого юрика где я учредитель и руководитель, а петлять от повестки по юрадресу - себе дороже.
Невнимательно прочитал, признаю.
Ненавижу мод_реврайт.
Изначальный код в топикстарте рабочий, переадресация происходит правильно, так что проблема явно в другом месте.
Вот скажите мне убогому каким образом оно подходит? И каким образом act вдруг оказался на первом месте?
"Чукча не читатель, чукча писатель" (с) анекдот
Да по идее в лоб должно работать:
RewriteRule ^index.pl?act=CONTACTS$ /contact [R=301,L]
Это максимальная память на ОДИН поток?
т.е. на самом дешевом одновременно два запроса кушающие по 500мб будут жить?
Ну и насколько я помню OOM Killer вызывается при исчерпании памяти и убивает кого-то одного, и не группирует их по пользователям.
Какие версии пхп присутствуют на сервере?
На что влияет лимит памяти на шаред-хостинге? Что происходит при его пиковом превышении?
Ну может ему дешевле такую денормализацию сделать чем JOIN-ить и т.п.
ТС ведь уперся в скорость а не в размер базы.
Подозреваю что если убрать группировку, странную сортировку и накинуть индекс, то ТС будет счастлив. А уже если это не поможет то да, нормализация, изучение планов запросов и т.п.
Не поймите меня неправильно, но если ТС строит запросы вручную а не через ORM и при этом плавает в этих самых запросах, то может не стоит усложнять структуру? Мы ведь не знаем сколько еще у него запросов к этой таблице. Сейчас нормализация, потом вьювы чтобы скрыть нормализацию от легаси, потом оптимизация вьювов... Может пока остановимся просто на исправлении запроса...
^ означает начало строки, так что это условие у вас не пройдет
Да тут можно на размер базы не смотреть - запрос неверно составлен, группировка без агрегации - явная ошибка и ее нужно исправить.
По сортировке я бы еще добавил свои пять копеек. Практического значения в данном вопросе они не имеют, но раз уж тут начали тыкать носом в мануал, то давайте разберемся. А почему собственно группировка вызывает именно такую сортировку? Разработчики мускула такие тупые что заложили лишнюю нагрузку по умолчанию или.... а, ну да, конечно, это ведь группировка. Агрегатные функции и все такое. Работа с сгруппированными данными, а память не резиновая. Я не утверждаю что это лучший способ, но мне кажется что если немножко подумать, то любому станет очевидно, что такая сортировка это артефакт алгоритма группировки а не желание разработчиков замедлить ваши запросы. Да, безусловно, такие хаки могут в определенных случаях ускорять работу, и ускорять существенно. Однако это требует экспериментального подтверждения и вообще не уместно в контексте изначально ошибочно построенного запроса.
