ThunderCat

у вас сравнивается "... время сейчас больше чем время сейчас минус 10 минут", что всегда будет true. вы там даже не упоминаете поле даты...

А может сначала по-православному? Индексы, слоулог, експлэйн...?

как уже заметил eRKa это логика уровня приложения, и к бд прямого отношения не имеет. Проверка должна выполняться в серверном приложении, и как верно предложил dollar - сначала селект - по результату инсерт.

Вариант делать перед insert-ом select (в котором проверять это условие) не подходит. Так как серия select-ов выполняется моментально, условие выполняется и затем все равно идет серия insert-ов.

Ошибка на фразе "срия select-ов выполняется моментально". Каждый селект будет выполняться ПОСЛЕДОВАТЕЛЬНО, при условии лока таблиц на чтение для инсерта. И ничего не выполнится моментально, все будет по порядку.

SET character_set_connection = utf8mb4;
SET character_set_client = utf8mb4;
SET character_set_results =  utf8mb4;

Вроде это при установке соединения указать надо, не уверен что они не сбиваются при клиентском подключении.
PS: не уверен, но вроде же COLLATE utf8mb4_general_ci;
тут еще посмотрите

В случаях когда у вас не предвидится использования отрицательных чисел, например индекс автоинкремент.

1) читать про join
2) читать про индексы тут, тут и тут.
3) составить запрос и прогнать его через explain.
4) Настроить индексы...
5) Profit

По умолчанию веста вроде фигачит бэкапы каждый день, пока место не кончится. Если вы не отключили бэкап, то просто поднимите из бэкапа последнее состояние.

Если данных не много и вы заранее знаете какие данные вам нужны для селекта просто получите их в json и используйте когда нужно. Если же данных много и они заранее не известны - запрашивайте их с сервера Аяксом. Можно даже в виде готового хтмл для селекта.

1) путь куда загружаете существует?
2) проверьте путь, не факт что вы его правильно указали( у вас путь читается от папки текущего скрипта, лучше использовать $_SERVER['DOCUMENT_ROOT'] и путь от него)
3) Права на папку куда пишете какие?
4) Ерор репортинг включите, отладка требует уровня E_ALL

Только UPDATE должен применяться

почему бы и нет?

update `users` 
set id = 42
where username = 'Duglas Adams'

UPD: как вариант логировать запросы на уровне прослойки бд, например по регулярке или вообще все. Хорошим решением так же будет по совету Rsa97 повесить внешние ключи на таблицу и отслеживать ошибки нарушения связанности.

Во первых:
$("#form").submit(function(e) {
e.preventDefault();
$.ajax({ ...
иначе форма будет пытаться засубмититься через раз( ретурн фалс не всегда срабатывает).

во вторых - консоль браузера смотрите, что уходит, что возвращается. По уму сервер по завершении работы должен отчитаться - "все ок", или "шеф, фсе пропало!". И уже о этого можно отталкиваться в яваскрипте что писать в алерт.

В третьих так же неплохо проверить что данные попадают в нужный скрипт, а то у вас довольно фривольно указан адрес куда аякс должен стучаться. Скорее всего скрипт тупо не понимает адрес который прописан, указывать нужно от корня сайта, например "/addguestbook.php"

всё будет в порядке Ровно до того времени пока вы не перейдете на зимнее или летнее время, и вот тут, в зависимости от того в какой стране прописана временная зона, спокойно может возникнуть разница в 1 час. опять же Это только в том случае если используется синтаксис mysql для вставки текущей даты, например функция now.

Элементарно, Ватсон. Поле текста новости - ckeditor? Если нет - ставим, и подключаем картинки из локальных папок.

`dialog_id` int(16) NOT NULL, - 16 отображаемых знаков - тут вроде не должно быть так, там может быть максимум (11) при int, и емнип в любом случае размер отводимой памяти будет 4 байта. Если вы планируете хранить более 4 миллиардов записей используйте bigint.

если вы мечтаете что из запроса магическим образом вернется готовый массив в таком виде, то никак. Запросы выдают одномерные массивы.

Можно выбрать так:

SELECT id, `product`.title, `product`.typeID, `type`.title, 
type`.typeID  type_typeID, type`.title  type_ttitle
FROM `product` 
LEFT JOIN `type` 
on `product`.typeID=`type`.typeID 
where `product`.typeID=1

после чего уже в коде по _ разбить в нужный формат.

Я бы не стал заморачиваться с поиском лучшего решения на пустом месте, если бы лучшая бд существовала, остальные бы умерли в неизвестности. В вашем случае я бы использовал MySQL, как минимум на начальном этапе, и вот почему:
1) Это бесплатно
2) Мускуль - хороший добротный середнячек своего класса, то есть он умеет почти все и при этом сильно не проседает по производительности.
3) На него ОГРОМНОЕ количество доков и юзеркейсов, а так же туториалов и советов по оптимизации в конкретную задачу.
4) При смене бд(если таковая понадобится) вам, скорее всего, придется только поменять драйвер бд(при условии грамотной архитектуры) и аккуратно перенести дамп базы.
5) Про MSSQL - до недавнего времени в ней не было нативной поддержки UTF-8, вместо нее была(и есть еще вроде) своя UCS, которая мультибайт, но какой-то свой(как всегда у мс), в свое время в угоду "скорости" ставили сервак с мсскулем, в итоге практически никакого прироста не получили, зато получили гемор с переводом кодировок.
6) Если проект реально нуждается в разрывном бд на пределе современных возможностей - смотрите в сторону инмемори бд, например тарантул или что-то носкюельное, типа редис и иже с ним.