xcache есть в пакетах убунту, а eacceleratorа нет.
в vbulletin в один период был "мертвый" код кеширования и его нельзя было использовать из-за каких-то там программистских проблем. в общем, родовая трамва конкретно у кода хранилища:
/*** Class for fetching and initializing the vBulletin datastore from eAccelerator** @package vBulletin* @version $Revision: 1.24.2.1 $* @date $Date: 2006/01/03 23:56:46 $*/class vB_Datastore_eAccelerator_This_Has_Problems extends vB_Datastore{
сейчас там этого нет, но осадочек то остался.
еще с каких-то давних времен сохранился такой веселый код :
if (version_compare($eaccelerator_version, '0.9.3', '<') AND (@ini_get('eaccelerator.enable') OR @ini_get('eaccelerator.optimizer'))){ return 'eaccelerator_too_old';}
то есть глюки были такие, что программисты специально запрещали запуск скрипта на eaccelerator 0.9.3.
получается, что в действительно широком использовании, каким подвергается только коробочный продукт, такой как vbulletin, eaccelerator довольно проблемный. У кого-то может и все работало.
это "самое вкусное" уже давно считалось проблемным. переходите на xcache
pikasso, ems это другая услуга и она дороговата, если, конечно, вы не торгуете "семенами" и прочими сверхприбыльными посылками.
T.R.O.N, внимание, это Почта России ! не путать с Royal Mail
они не напишут.
Везде в российских интернет-магазинах все довольно грустно с этим видом доставки. или указывают цену без доставки или накидывают сразу много на всякий случай.
вот именно этот случай я и имел ввиду. В вашем запросе sql волен будет выдать в каком угодно порядке поля где view совпадает. Это и нужно стабилизировать добавляя дополнительное да еще и уникальное поле для сортировки. Получаете предсказуемый порядок и все отлично.
нету и даже это неправильно.
нужна двойная сортировка order by views,primary_id и условие primary_id>NNN чтобы полностью стабилизировать порядок.
но если там идет расчет чего-то для каждого значения в таблице, то можно в сессионных переменных mysql хранить предыдущие значения и использовать эти значения в вычислениях. техника несколько непривычная и неудобная, так что нужно взвесить стоит ли.
Zaqwr, как обычно, ничего. надо сначала понять действительно ли на диски идет хорошая нагрузка от оракла. Кстати, там есть гораздо более интересные способы заморочиться, вплоть до построения дисковых массивов на уровне приложения
вполне укладывается в теорию : "оптимизация" это пересоздание файла с таблицей. Вероятно содержимое и индексы такой таблицы сразу попадают в кеш ОС и все другие данные других пользователей вытесняют. На некоторое время.
На выделенном сервере все ресурсы и так только ваши, поэтому эффект не столь заметен.
mr.Cent, а то, что у вас у вас примерно 20 минут не будет доступна база, запросы скопятся, сайт перестанет открываться, яндекс обидится и пометит вас крестиком, вас не волнует?
выигрываете вы не так уж много.
http://dev.mysql.com/doc/refman/5.1/en/optimize-table.html
этот источник для вас достаточно авторитетный ?
zexis, убрать пустое место от удаленных записей из таблиц. практически только это. никакого волшебства. на обычные индексы практически не повлияет.
впрочем, если есть fulltext-индексы, считается что такие таблицы cтоит оптимизировать почаще.
