Да, в DC15 потери пакетов. В DC19 чуть лучше, но тоже не ахти.
Да действительно, сорри.
Но в любом случае мой комментарий корректен - по выходным Хетцнер обслуживает только основные серверы.
В Хетцнере техники по выходным работают, и все там ок по выходным с обычными серверами.
(врочем вы и так это знаете прекрасно, просто прибежали сюда плюнуть при случае)
Но они не саппортят low-end серверы и vps по выходным.
Я бы не стал брать критичный vps напрямую у Хетцнера - для этого есть куча ресселеров, которые продают серверы, порезав их на vps'ы.
Во-первых, innodb использует свой буфер для кеширования и данных, и индексов - и это конфигурируется в my.cnf, а myisam для данных использует буфер операционной системы.
Чем больше таблица, тем это критичнее.
Вполне возможно что у хостера почти вся память отдана под innodb буфер, поэтому myisam тормозит.
Во-вторых, данные в innodb таблице упорядочены по первичному ключу и запросы по первичному ключу требуют меньше io операций - критично для больших таблиц.
В-третьих, использовать myisam - это просто дурной тон, это ненадежное хранилище (может потребовать восстановления данных специальными командами).
Вы видимо себя имеете в виду, потому что мы выяснили уже тут на форуме что вы все судите по "типичным сайтам" - это и есть признак недалекости.
К хабрастартаповцам я никакого отношения не имею, как и к стартапам вообще.
Я бы первым делом конвертировал таблицу в innodb.
Только после этого можно начинать какие-то оптимизации.
Это проверяется и без slow log:
flush status;
select ...тут наш запрос...;
show status like 'Handler_read_%';
Только я не знаю как ОП будет у себя запускать через этот веб-интерфейс :)
Если и правда шаред-хостинги не тянут select'ы по primary key на таких таблицах, то это конечно жесть, как они еще не вымерли.
Здесь дело не в хостинге, а в mysql оптимизаторе. Он хочет перебрать все строки в таблице, хотя запрос только по первичному ключу.
Может древняя версия mysql установлена.
4 миллиона строк - это не много для запроса по ключу.---------- Добавлено 28.08.2013 в 16:25 ----------
Да, это я проглядел, там только 1 поле.
Но в запросе по ключу в explain rows не должно быть 4 миллиона.
SELECT abonentname, abonentid, phone FROM phones ORDER BY id ASC LIMIT 2279900,100;
Этот запрос означает, что бд будет перебирать 22+ миллиона записей каждый раз, чтобы выполнить его.
Запрос менять не надо, надо добавить в таблицу индекс phone_id (phone, id).
Затем еще раз посмотреть explain - в поле key должно быть phone_id.
Если нет, значит в select надо будет добавить force index phone_id.
Почему же? Я репрезентативен с точки зрения владельцев сайтов.
С точки зрения vps-хостеров - может быть не репрезентативен. Но внутри vps'ов может быть не все правильно настроено, и vps может создавать много чтения.
И еще про это.
Поисковики сканируют любой сайт, и чем сайт успешнее, тем больше страниц сканируется, и скорость сканирования выше.
Это создает значительную нагрузку если вы полагаетесь только на кэш.
У меня количество страниц в гугле исчисляется сотнями миллионов - но вообще это справедливо для любого сайта.---------- Добавлено 27.08.2013 в 14:51 ----------
Общие тенденции - это микро-сайты, которые никогда не взлетят.
Я говорю о популярных сайтах.
