Shedal

Не работает ваш запрос потому, что вы из подзапроса обратно выбираете тот же самый user_id, который «подали вовнутрь». Иными словами, ваш запрос идентичен следующему:

SELECT U.*, S.*
FROM `user` AS U
LEFT JOIN stats AS S ON S.user_id = U.id
WHERE U.id = 1

Как правильно сделать, уже написали выше. ИМХО, вариант с группировкой будет лучше всего, и читабельнее тоже. Хотя лучше сравните производительность на реальных данных. На всякий случай, держите сам запрос:

SELECT u.*, MAX(s.date) max_date
FROM user u
LEFT JOIN stats s
  ON s.user_id = u.id
WHERE u.id = 1
GROUP BY u.id

Делать 4 таблицы (коммент запроса, похожие фильмы запроса, коммент ответа, фильмы ответа) не очень хочется во нескольким причинам:
слишком много запросов в БД будет на получение списка запросов на просмотр (запрос, фильмы, кто, что советует)
слишком много лишних телодвижений будет и при ответе

Что значит слишком много? По сравнению с чем?

Вообще, 4 таблицы — это будет нормализированный способ хранения ваших данных. Можно и денормализировать, но это ухудшит расширяемость и возможности по манипуляци данными средствами SQL. Иногда денормализация приемлема, просто нужно в полной мере осознавать, какими будут последствия.

Например, можно сделать две таблицы: Comments и CommentMovies. В Comments добавить поле IsQuestion, в котором хранить TRUE, если это вопрос и FALSE, если это ответ. CommentMovies будет хранить фильмы как для вопросов, так и для ответов.
Минусом такого подхода будут проблемы функциональной расширяемости. То есть, если вы захотите добавить в таблицу Comments поле, присущее только вопросам, то у вас будет, по сути, три пути:
1) Рефакторинг структуры: разделение на ваши исходные 4 таблицы. Это трудозатратно;
2) Добавление ещё одной таблицы: QuestionCommentFields. Структура получается корявой;
3) Создание поля, которое будет хранить значения только для одного типа строк. Это уже денормализация.

Можно фильмы хранить в виде строки в основной таблице, перечисленными через запятую. Это денормализация, она упростит структуру, но усложнит и замедлит изменение и поиск данных.

В общем, выделите для себя какие-то приоритеты и путеводные камни. Будет ли структура часто меняться в будущем, важна ли простота поддержки? Важна ли скорость выполнения запросов, важна ли возможность менять данные напрямую SQL'ем? И т.п.

Как вариант, можно создать таблицу translations (text, culture, translation).

Определить функцию translate(text, culture), которая будет возвращать или перевод, если он есть, или изначальную строку, если перевода нет.
Использовать её можно будет с любой таблицей:

SELECT Id, translate(Value), translate(Value2) ...

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

Это совсем не обязательно кэш.

Во-первых, при выполнении запроса MySQL подгружает в память все необходимые индексы. Если сразу после этого выполнить запрос повторно, индексы уже находятся в памяти, и это уменьшает время выполнения запроса.

Во-вторых, MySQL также на время кэширует план выполнения запроса.

как от этого избавиться?

Я не думаю, что от этого стоит (или даже можно) избавляться. Вреда никакого, одна сплошная польза :)

Я сильно сомневаюсь, что есть трояны, специально ориентированные на SQLyog. Ну, а в рамках нормальной гиковской паранойи :) можете поставить йога в виртуальную машину. И не запускать там троянов :)

Я не видел ни одного MySQL-клиента, который бы при запоминании пароля позволял дополнительно защитить его мастер-паролем.

У меня с вот таким синтаксисом никогда не было проблем:

DELIMITER $$

DROP PROCEDURE IF EXISTS `sp_test`$$

CREATE DEFINER=`user`@`%` PROCEDURE `sp_test`(
	IN Number INT
	)
    READS SQL DATA
BEGIN
	-- 
	-- Код здесь
	-- 
END$$

DELIMITER ;

Поинтересуюсь: а зачем вам запускать хранимые процедуры из IDEA?

Я ставил SQLYog в виртуальную машину и радовался жизни.
А если нужен нативный клиент, то, говорят, Navicat for MySQL неплох.