А зачем? что плохого в двух запросах лично для вас?
в стратегически неправильном выборе ОС. Zend не поддерживает freebsd больше.
Наверняка что-то можно сделать, типа доустановки эмулятора linux. Но проблема именно в том, что я написал.
Действительно, запихайте побольше данных. Способ выполнения запроса у mysql зависит от текущих данных, а не только от структуры. С ростом объема он может поменяться и может случиться неприятный сюрприз.
Ваш случай специфический: несмотря на созданный индекс mysql прогнозирует почти то же самое число затронутых строк что и без индекса. Накладные расходы на последовательное считывание таблицы в произвольном порядке (ALL) как она лежит на диске могут оказаться меньше считывания в порядке индекса потому что файловые системы и диски легче справляются с последовательным чтением.
Что касается filesort : именно так обозначается сортировка вообще, не обязательно во временном файле, несмотря на слово file в названии. То есть не обязательно все очень плохо. Использование сложных составных индексов разумеется влияет на скорость обновления таблицы. Тут бы не перестараться изгоняя filesort.
Ну и выложите базу, поди не секреты какие.
Мне ваши результаты explain кажутся странными. Самый очевидный индекс следовало делать по talk_last_comment_timestamp, но похоже из-за desc он не используется. Комментарии ведь равномерно разложены во времени,а все остальные индексы с низкой селективностью. Данные в talk_last_comment_timestamp реальны или забиты мусором для тестирования ?
netwind добавил 09.03.2010 в 21:09
Вот пришел домой и попытался сгенерировать данные как смог - talk_last_comment_timestamp равномерно распределен среди 3000 записей. В моем "мусоре" все отлично :
+----+-------------+-------+--------+---------------------------------+-----------------------------+---------+-------------------+------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+--------+---------------------------------+-----------------------------+---------+-------------------+------+-------------+ | 1 | SIMPLE | t | index | talk_activity,talk_comments_qty | talk_last_comment_timestamp | 5 | NULL | 27 | Using where | | 1 | SIMPLE | u | eq_ref | PRIMARY | PRIMARY | 4 | sehelp1.t.user_id | 1 | | +----+-------------+-------+--------+---------------------------------+-----------------------------+---------+-------------------+------+-------------+
а вы проверили, что c других ip действительно нельзя подключиться?
это потребует либо доступа от другого провайдера, либо передать пароль другу ( у которого вполне может не быть антивируса)
А какая тут может быть ошибка, если в каждом свитче есть совершенно конкретное ограничение на количество mac-адресов в таблице? логика производителя простая: если таблица закончилась, то нужно передавать трафик во все порты чтобы хоть как-нибудь работало. Другое дело, что клиенту незачем иметь более одного mac-а на порту. Но для реализации этого ограничения свитч уже должен быть непростым. И это не хаб.
Ну не будем же мы тут учить молодежь плохому. "Соответствующее оборудование" на удивление банальной конструкции.
И относительно неплохие свитчи быстро превращаются в хабы, если им забить таблицу маршрутизации.
думаю, что андрейка перефантазировал. Однако, если настойчивый сосед знает о ваших увлечениях и завидует, то он найдет способов поснифать даже у хороших провайдеров. А уходить от такого провайдера не всегда можно и выгодно.
myhand, а чем можно наказать магистрального провайдера, благодаря которому российский трафик периодически проходит через оборудование расположенное в странах НАТО ? )
Шутка, но кто знает.
ну ставьте триальный на 21 день, а там видно будет.
Если под Remote Systems имеется ввиду удаленная отладка, то попробуйте komodo ide. Пиратский, ага. Как и зенд студио.
