Тимофей

$ mysqldump -u username -p'password' db-name | ssh user@remote.box.com mysql -u username -p'password db-name

Думаю, что это самый простой вариант

Вы же сами пишете «при explain сама выборка не производится» и в то же самое время хотите получить результат, который может получится _только_ при выборке из БД. Вам не кажется это, как бы сказать, абсурдным?

Вообще, если предположим, что explain select сделает-таки выборку, то однозначно, что если кроме показа результатов выборки он еще и будет разрисовывать то, как выполняется запрос — то для этого надо дополнительное время. А значит, это будет выполняться дольше, чем простой select.

>>Стоит ли в этом случае делает индекс составным и кластеризованным?
Составной индекс по паре (time, account), для отбора по экаунту наверняка вам будет бесполезен. А для отбора по экаунту и диапазону времени (или с сортировкой по времени и отсечкой по top/значению времени), он будет существенно менее эффективен нежели по паре (account, time)

Наверняка отбор по экаунту производится с сортировкой по time и отсечкой по time либо же top, либо же по диапазону time. В этом случае, мне думается, будет уместен составной индекс по паре (account,time)

Вот кластеризованный — ли, берут меня сомнения. Нужны дли вам на столько дополнительные пять копеек при отборе, чтобы можно было чуть пожертвовать производитеьностью на вставке? Полагаю — врядли. Скорость вставки, мне думается, тут весьма критична будет.

Чем возиться с непонятным и возможно уже умирающим винтом не проще ли купить новый?

Стоят ли у вас индексы на таблицах?
Sphinx это поисковой движок, при коротком времени обновления индекса у вас будет свежая инфа в индексе.

Но мне кажется вы что-то делаете не так:
Зачем собственно выводить данные из индекс sphinx, а не напрямую из бд? Если проблема только в скорости значит у вас проблемы с запросами. Необходимо проанализировать запросы через EXPALIN и проверить наличие и использование индексов.

правильно, с точки зрения нормализации вариант №1, когда нет дублирующей и зависимой информации. Если это не критичное для производительности место, то лучше не создавать лишних сущностей.

Но если запрос такого рода часто используется или выполняется медленно, то стоит ввести дополнительное поле. Имхо лучше делать триггер на изменения в таблице с комментариями и в нем апдейтить поле в таблице с постами, сделать для него дефолт в 0 и вообще забыть о его модификации в приложении.

По-моему, второй вариант предпочтительней. Он полностью избавит от головной боли в будущем, когда количество данных может увеличиться. Эффективней тратить вычислительные ресурсы в моменты, возникающие реже — в данном случае, добавление/удаление комментариев происходит значительно реже, чем их просмотр.
Реализовать эту логику можно с помощью mysql триггеров, которые будут автоматически обновлять число комментариев при каждом добавлении/удалении

CREATE TRIGGER `comment_add` AFTER INSERT ON `post_comments`
FOR EACH ROW BEGIN
SET @post_id = NEW.post_id;
SET @comments_num = (SELECT COUNT(id) FROM post_comments WHERE post_id = @post_id);
UPDATE `post` SET `comments_num` = @comments_num WHERE `id` = @post_id;
END;


Полный дамп тут

У меня на роутере так:
#вписываем гарантированную и максимальную пропускную способность интерфейса
tc class add dev $WAN parent 1: classid 1:1 htb rate 5mbit ceil 5mbit

Напряжение написанное на конденсаторе показывает по сути его запас прочности. Подадите более высокое — его пробьет. Вы просто увеличили «запас прочности» конденсаторам, и ничего более. Если погуглите на тему блоков питания — ставить конденсаторы с запасом по напряжению рекомендуют практически все, единственное ограничение здесь — запас лучше делать разумным, т.к. конденсаторы бОльшего вольтажа, как правило, крупнее и дороже.
По поводу увеличения емкости — совет верен в отношении фильтров блоков питания, но не в остальных случаях (скажем, если вы значительно измените емкость конденсатора в кроссовере колонок, вы измените частоты среза и вероятно подпортите звук). В традиционных трансформаторных блоках питания (с импульсными не знаком) конденсатор гасит пульсации, там с увеличением емкости увеличивается и подавление пульсаций, но при этом на старте значительно возрастает ток первичной зарядки конденсатора.

на OpenVZ время внутри машины менять нельзя, только временную зону. Так что просто проверьте, что на самом OpenVZ время идёт правильно — в этом может быть ошибка. Потом, вы неверно настраиваете часовой пояс. Про это немногие знают, но надо так:
1) заполнить файл /etc/sysconfig/clock как вам сказали, но параметр UTC скорее всего будет true — он говорит о том, что внутренее время компьютера установлено по UTC, и для *никс систем это как правило именно так.
2) выполнить
/usr/sbin/tzdata-update
После этого файл /etc/localtime обновится и всё будет как положено.

htc wildfire отключил синхронизацию с данными сотовой сети — часы назад убегали (МТС Новосибирск).
Теперь все нормально.