ivnik

Например так:

select t1.*, c.user as `last_user`, c.datetime as `last_date` from topics as t1 inner join (select id_topic, max(id) max_id from comments c1 group by id_topic) t2 on (t2.id_topic = t1.id) inner join comments c on (c.id = t2.max_id);

Использовать ORDER BY для поиска максимального элемента не очень хорошая идея (хотя вроде оптимизатор mysql при использовании ORDER BY и LIMIT понимает, что сортировать не нужно)

select t.* from tree t left outer join (select id, max(changetime) changetime from tree_sync where user_id=2 group by id) ts on (t.id=ts.id) where ts.changetime is null or ts.changetime < t.changetime

1) Если беспокоит производительность, то удалённые записи переносить в отдельную таблицу.
2) Если объёмы таблиц не большие/не требуется высокая производительность, то делать как посоветовали выше, дополнительным флагом. В этом случае лучше сделать view, чтобы уменьшить объём рефакторинга, если захочется поменять логику (т.е. например вынести удалённые записи в отдельную таблицу или изменить способ работы с флагом удалённых записей). Сам флаг я бы делал NOT NULL и естественно добавил бы в индексы.

P.S. у меня был похожий случай, когда надо было хранить ссылки на удалённые записи, мы использовали hibernate + envers (java). Классы/поля с аннотацией @Audited порождали name_AUD таблицы, в которых хранились все те же данные, плюс два дополнительных поля — номер ревизии и тип ревизии (создание, изменение, удаление). Существовала отдельная таблица с информацией о ревизиях с полями номер ревизии, дата ревизии и дополнительные наши поля (например логин, ip-адрес). Одной транзакции соответствовала одна ревизия. Хотя, возможно этот вариант для вашей задачи слишком навороченный, привёл его просто для примера альтернативного варианта.

Вероятно виновата база данных. В стандарте SQL (http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt):

There are three classes of datetime data types defined within this
International Standard:

— DATE — contains the <datetime field>s YEAR, MONTH, and DAY;

— TIME — contains the <datetime field>s HOUR, MINUTE, and SECOND;
and

— TIMESTAMP — contains the <datetime field>s YEAR, MONTH, DAY,
HOUR, MINUTE, and SECOND.

Т.е. миллисекунды не хранятся.

Посмотрите метод prepareStatement:

  pstmt = con->prepareStatement("INSERT INTO test(id) VALUES (?)");
  for (int i = 1; i <= 10; i++) {
    pstmt->setInt(1, i);
    pstmt->executeUpdate();
  }
  delete pstmt;