Rsa97

Если надо не только добавлять, но и удалять:
Сначала пометить все строки как неизменённые
UPDATE `table` SET `updated` = 0;
Затем добавить все записи

INSERT INTO `table` (..., `updated`) 
  VALUES (..., 1) 
  ON DUPLICATE KEY UPDATE `updated` = 1;

В конце удалить строки, оставшиеся неизменёнными
DELETE FROM `table` WHERE `updated` = 0;

Делать JOIN таблицы с ней же по условию "похожести".

А вы проверяли, какую ошибку выдаёт при этом MySQL.
Синтаксис MySQL допускает использование ORDER BY только после GROUP BY.

GROUP BY FLOOR(`time` / 3600)

Для начала определитесь, какую подпись будете использовать. Будут ли пары ключей выдаваться вашим сервером или вы будете использовать ЭЦП аккредитованных вами УЦ. Если подписи генерируются у вас, то будут ли оба ключа храниться на сервере или закрытый ключ будет только у пользователя.

В любом случае перед подписанием документа необходимо сформировать его хэш. Для этого крайне желательно интегрировать в документ все ресурсы, на которые он ссылается (шрифты, вложенные документы, картинки и т.д.). Затем выделяется часть документа, которую необходимо закрыть подписью (в простейшем случае - это весь файл документа) и по ней вычисляется какой-либо хэш. Этот хэш шифруется закрытым ключом, полученный зашифрованный хэш и является подписью.

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

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

Делайте уникальный ключ по (upc, sku). Затем

INSERT INTO `product` (`upc`, `sku`, `price`, `price_retail`)
  VALUES (:upc1, :sku1, :price1, :price_retail1), ..., 
         (:upcN, :skuN, :priceN, :price_retailN)
  ON DUPLICATE KEY UPDATE `price` = VALUES(`price`), 
    `price_retail` = VALUES(`price_retail`)

Только следите за длиной строки запроса, переменная max_allowed_packet

Ещё вариант - использовать подготовленный запрос. Один раз перед циклом делается prepare и bind, затем на каждом шаге execute. Экономия идёт на компиляции запроса.

Сейчас не вспомню точный вариант, но для синхронизации выборки по одной строке я пользовался назначением переменной в команде UPDATE, примерно так:

UPDATE `table` 
  SET `onWork` = 1, `timestamp` = NOW() 
  WHERE `onWork` = 0 AND (@id := `id`) > 0
  ORDER BY `timestamp`
  LIMIT 1

А затем уже выбирал эту строку

SELECT * 
  FROM `table` 
  WHERE `id` = @id

Ну и после обработки

UPDATE `table`
  SET `onWork` = 0, `timestamp` = NOW(), ...
  WHERE `id` = @id

if ($resultAddMus = 'true')
Во-первых, у вас вместо сравнения стоит присваивание. Чтобы таких ситуаций было меньше, используйте стиль Йоды.
Во-вторых, вы пытаетесь сравнить не с логическим значением, а со строкой.
В-третьих, для логических значений сравнения не требуется, достаточно простого
if ($resultAddMus)
Ну и, наконец, SQL-запрос у вас неверный. Вставляемые строки должны быть в одиночных или двойных кавычках. А ещё лучше использовать подготовленные выражения с плейсхолдерами.

В вашем примере речь идёт, скорее, не о порядке сравнений во WHERE, а о порядке колонок в индексе.
При поиске используется только начальная часть составного индекса. То есть индекс (a, b, c) можно использовать при поиске по a, ab или abc. Поиск по b, c или bc использовать такой составной индекс не будет.

Обратите внимание на строчку 'rows' в ответе EXPLAIN'a, подозреваю, что у вас в таблице всего семь строк, а значит запрос просмотрел их все, не воспользовавшись индексом.

Эврика! Здесь говорится, что в случае покрывающего индекса (а здесь именно такой случай) записи индекса используются для ускорения доступа к данным при переборе, так как записи индекса, в общем случае, занимают меньше места и расположены компактнее, чем записи самой таблицы.

JSON есть смысл использовать исключительно для хранения данных. Если по данным нужен поиск, сортировка, слияние таблиц - только классическая многоколоночная/многотабличная структура.

ЕМНИП, при хранении проблем нет, есть проблемы при поиске и сортировке. VARBINARY и ищет и сортирует не посимвольно, а побайтово. В результате большая и маленькая буквы для VARBINARY - это разные строки.

SELECT * FROM `user` WHERE `login` = ?

Найти все пересекающиеся интервалы и длительности пересечения несложно:

SELECT `i1`.`i`, `i1`.`o`, `i2`.`i`, `i2`.`o`, 
       (IF(`i1`.`o` > `i2`.`o`, `i2`.`o`, `i1`.`o`) 
        - IF(`i1`.`i` > `i2`.`i`, `i1`.`i`, `i2`.`i`)) AS `crosstime`
  FROM `table`  AS `i1`
  JOIN `table` AS `i2` ON `i2`.`id` > `i1`.`id`
    AND `i1`.`i` < `i2`.`o` AND `i2`.`i` < `i1`.`o`

Затем можно добавить группировку, и вычислить SUM(`crosstime`)

https://habrahabr.ru/post/245233/

Первый же пример в руководстве. Только DSN на свой замените и тип изображения укажите правильно.