Вячеслав Успенский

Я конечно дико извиняюсь за оффтоп, но от вашего стиля глаза выпадают.
во первых разделите логику и отображение
во вторых для вывода внутри html шаблонов удобней использовать <?= foreach:/endforeach

<?php
$var=123;
?>
<div>
<h2><?=$var?></h2>
Some text
</div>

В чем проблема завести автоинкрементальное поле?
Если не нравится автоинкремент на 1 то берете созданную последовательность и меняете как вам вздумается.

Напишите реальный пример где и зачем вам это нужно, без допустим.

$lastsimbol='Last symbol|';
$lastsimbol=substr($lastsimbol, 0, -1);
echo $lastsimbol;

socialcompare.com/en/comparison/javascript-graphs-...

Скиньте ваш неоптимальный запрос, даже если он с групировкой и having и план к нему, тогда можно прикинуть ка ктоже самое сделать оптимально (писать с нуля малость лениво)
Но имхо вам сразу бы смотреть в сторону от mysql

Я бы рекомендовал во первых ввести заголовок. Скажем история выглядит примерно так

25.02.2015 Начислено 50 баллов за взрыв вертолета
То полностью сохраняем заголовок (можно параметризованный). История возможно многим захочется посмотреть, а вот перейти на ссылающийся объект куда меньшему числу,

Очки я бы суммировал в отдельной таблице в профиле пользователя, лучше потратить лишнее время при инсерте, чем 100500 раз суммировать.

Ну и в принципе можно еще извернутся и сделать основную таблицу, и ее потомков под каждый table_name.
Тогда можно сделать скажем insert into scores_by_lessons, select * from scores by_lessons
ну и в любой момент select * from scores для общего журнала. Тут уже вопрос предпочтений)

А в чем проблема? В руководстве что вы дали в конце просто curl xput
Ничто не мешает вам так же пихнуть любые данные.

По первому: наиболее секурно все же отдельные виртуальные машины.
Однако если вопрос только в БД, при условии нормальной архитектуры самого приложения и бд скажем PostgreSQL/Oracle То я бы остановился на схемах. Причем каждый поддомен работает от своего пользователя/схемы с четко разграниченными грантами.
С управляющей схемой контактируют только системы полностью изолированные от пользователя.
Начальное копирование баз для posgre, скажем: от простого дампа основной схемы/create table like до create table of type / inherits

По второму пункту: при грамотной реализации ничего тормозить не будет, во всяком случае у меня 250млн сообщений при 2тысячах активных пользователей не тормозили абсолютно. Тут больше думать нужно над реализаций самих сообщений. Если скажем мы можем удалять свое сообщение из переписки то его копия не нужна, если не можем то табличка вида
-message_id
-message_text
-message_theme (если нужно)
-parent_id (для иерархии ответов, если нужно),
-folder_id (если нужны папочки)
-author_id
-author_name
-recipient_id
-recipient_name
-keeper_id
Решает все проблемы. На каждое сообщение создается два экземпляра и соответственно если keeper_id==author_id то это исходящее, если keeper_id==recipient_id - входящее. Имена отправителя/получателя кешируем в соответствующих полях дабы не выполнять на каждый чих лишний джоин а так же дабы не потерять адресата если вам захочется потереть пользователя из бд (что само по себе плохая идея). Определяемся нужны ли темы,папки итд и составляем индексы под наши запросы - все: радость и счастье, бабочки летают.

Проверьте error лог mysql.

Попробуйте сдампить и импортировать одну таблицу и посмотреть что будет происходить.

ЗЫ Банальность но все же: место на диске есть?

Такой запрос к таблице применяться не может, у вас в селекте есть поля не участвующие в группировки и без применения агрегатных функций.
Покажите explain запроса и show create таблицы.

Судя по времени выполнения отсутствуют или неправильно расставлены индексы. Таблицы без шардирования?

ЗЫ Если не хотите публично светить данными то можно и лично, но уже в разрезе оплачиваемой работы.

Используйте партиции, тогда у вас не будет таких проблем. Однако учтите что у MySQL на больших секционных таблицах есть проблемы с каскадными констрейнами.

dev.mysql.com/doc/refman/5.1/en/partitioning.html

почитал ветку комментов под предыдущим ответом, к сожалению не понимая что именно вы делаете трудно советовать, но: выберите подзапросом DISTINCT rnn а затем к нему джоином всю остальную выборку.

for ($i=0; $i<15; $i++)
  {
  echo $arr[$i];
  }

man cron

Если вы вставляете в базу из приложения то там же и организуйте оповещение всех связанных объектов.
Если сторонними методами то таймер - вполне нормальное решение, но запрос лучше использовать prepared (если у вас драйвер использует нативные prepared ане эмуляцию, но под нод я вроде таких не видел)

Уже выше ответили, но у меня есть уточнение: зачем вы это делаете? Может быть вашу задачу можно решить при помощи css анимаций?

Варианта три:
1. чуть дописываете ваш пхп скрипт до:
myMap.geoObjects.add(myPlacemark);
и подключаете это дело скриптом
2. Выкидываете из пхп вывода скрипты и оставляете json, грузите ajax'ом и выполняете добавление на основе аякс данных
3. Включаете скрипт прямо в файл, который и рисует саму карту