Adamos

UNIQUE индекс на эти три столбца + INSERT IGNORED

Или все комментарии к определенному кондиционеру

Сначала надо не запутаться в терминологии и определить, что такое "определенный кондиционер" - это конкретная балалайка у конкретного клиента или конкретная модель, по которой вы будете собирать отзывы?
Впрочем, данных у вас будут не миллионы строк, так что достаточно просто соблюдать нормализацию - вытянуть их проблемой не будет.
Если вам так важно обрабатывать именно комментарии, сделайте избыточную таблицу, где в каждой строчке будет писаться вся нужная информация - и заказчик, и техник, и модель, и идентификатор устройства...
Кстати, возможно, стоит разделить комментарии техника - об устройстве и о клиенте ;)

sudo apt-get install vagrant virtualbox git
git clone https://github.com/scotch-io/scotch-box ~/my-project
cd ~/my-project
vagrant up

AND могут быть не только в WHERE, но и в ON.
Если в них не результаты, а поля - именно там им и место.
Ну, и чудовищный IN и длинное сочетание AND-OR стоит превратить в подзапрос, имхо.
Может быть, и остальные условия собрать в подзапрос перед JOIN, если они отсекают достаточно много полей....

Ну, попробуйте установить "нулевое значение" для даты или логического поля.
Внезапно, это будет 1970-01-01 и false, а не какое-то "отсутствие значения".

Кроме того, NULL - это значение поля при LEFT JOIN в случае, если во второй таблице не нашлось подходящей строки. Опять-таки - не нулевое значение, а его отсутствие.

localhost - это та машина, на которой вы работаете.
Вам же нужно указать сетевой адрес виртуалки.
Скорее всего, по умолчанию доступ к БД извне закрыт - нужно будет его разрешить.

Я бы начинал думать с вопроса "а зачем здесь именно реляционная база данных и что от нее на самом деле потребуется?".
Если не знаете ответа - присмотритесь к базам, специально заточенным под хранение документов.

Лучший способ ускорить WAMP - это вынести его за подоконник.
Гравитация придаст ему необходимое ускорение.

SELECT e.`id`, e.`name`
FROM `news` e 
ORDER BY DATEDIFF(NOW(), e.`date`) ASC
LIMIT 20

Собственно, формулу можно и усложнить, если вы понимаете, что на самом деле хотите получить от двух сортировок в разные стороны.

Начинаете транзакцию.
Обрабатываете строки.
По тому же условию обновляете строки.
Завершаете транзакцию.

Это, на самом деле, будет проще и надежнее любых хитро составленных запросов.

Не стоит тратить свою юность на mysql_ - функции. Они мало того, что ужасны, так еще и устарели.
Пока вам не требуется сложная работа с базой, можно пожить, например, с SafeMySQL. Это, конечно, не панацея и в перспективе вообще тупик, но по сравнению со спагетти из функций - радость и благорастворение воздухов.

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

Если у вас тяжелые внешние ссылки, сделайте ленивую загрузку. Хотя бы элементарно - выводите страницу со всей версткой, но без конкретики, а в конце пишите javascript, который назначает конкретным картинкам конкретные src. Это несложно, правда. Впрочем, если для этого познакомиться хотя бы и с общеизвестным JQuery, все станет еще проще...

var t = new Date();
t.setTime(<?= strtotime('now') ?>);
write(t.toLocaleTimeString());

Обычное решение - JOIN таблицу саму с собой ON idUsr и date(time) равны, а id разные.

SELECT `id`, `num` FROM `table` HAVING `active`=1 AND `num`=MAX(`num`)

Я бы сделал кроме личных сообщений - оповещения (те, которые всем). Можно в той же таблице, просто с нулевым адресатом.
И к ним дополнительную таблицу - последний id оповещения, которое получил пользователь.
Все оповещения, которые еще им не были получены, выдаются ему при первом же входе, при этом в таблицу заносится id последнего выданного.
Хотя им неплохо бы и срок жизни иметь - через год-два смысла в них точно не будет...

Входящие данные не надо защищать. Их нужно очищать от потенциально опасных включений.
Если данные пойдут в базу - пропускать их через плейсхолдеры и никогда не включать в запросы "сырые" строки.
Если данные будут выводиться пользователю - превращать любые символы, используемые в разметке, в HTML-версию этих символов.
Если данные сохраняются в файлы - убедиться, что в этих файлах именно данные ожидаемого типа и что они недоступны по прямому запросу.
Ну, и внутренняя логика не должна зависеть от входящих данных - все управляющие элементы должны оставаться на сервере, так как снаружи может прийти все, что угодно. В принципе.
Конец статьи.