Владимир Скибин

Используйте pool соединений

Вам не нужен декремент, его роль будет выполнять дельта = текущее время - время окончания (которые Вы вносите в базу). А тикер можете делать хоть каждые пол секунды для показа информации. В базе ничего не надо менять, только показывать дельту.

Что и куда Вы закинули?

Соединение с базой данных у Вас идет через localhost. Соответственно ничего не соединится, если у Вас не установлен mysql на устройстве, либо соединяйтесь по внешнему IP для СУБД

Могу посоветовать разве что хранимую процедуру, которая и будет делать нужную Вам таблицу и добавлять дополнительный столбец, который инкрементировать при смене user_id. Тогда сможете сделать group by по новому столбу и по нему же отсортировать. Т.е. у Вас получится что то типа
SELECT `t`.*, COUNT(*) AS `count` FROM my_func() AS `t` GROUP BY `newcol` ORDER BY `newcol`;
А my_func - должен возврщать таблицу путем полного последовательного перебора перебора данных.

Для шифрования в своей практике использовал шифрование и расшифровку именно на уровне приложения (правда было приложение на nodejs). В базе хранились шифрованные данные и передавались по каналу связи аналогично шифрованные данные. Их расшифровкой и проверкой целостности занималось как раз приложение. Ключ для расшифровки указывался один раз при запуске приложения. Это лишало возможности автономного перезапуска приложения, но как раз давало возможность не хранить ключ в явном виде (в файлах). При "скачивании" зачастую редко делается "дамп" оперативной памяти, на что и была сделана собственно ставка плюс к этому были подключены дополнительные системы мониторинга для ограничения доступа, контроля целостности. Таким образом базу данных можно было хранить хоть в открытом источнике (недовенренном датацентре), а пароль для запуска приложения был составным.
Быстродействие приложения конечно немного просела, но того требовали условия его использования. И да, шифровались только те данные, которые не участвовали в поиске / индексации.

Вам как раз правильно гугл подсказал. Сама идея заключается в том, чтобы брать один коннект из пула и в рамках него уже делать всю транзакцию. Дедлок Вам говорит о том, что несколько запросов пытаются обратиться/изменить к одним и тем же данным. Можете решить этот вопрос при помощи транзакций, только нужно подобрать правильный уровень изоляции. Например, при самом строгом SERIALIZABLE Вам придется повторять транзакцию как раз при получении ошибки синхронизации.
https://dev.mysql.com/doc/refman/5.6/en/innodb-dea...
https://stackoverflow.com/questions/43625542/er-lo...

Промониторьте SHOW PROCESSLIST и htop в течение часа, таким образом Вы точно выясните верно ли Ваше предположение.

А теперь открой эту страницу в 20 вкладках и посмотри на нагрузку.
Если хочешь чат - то смотри в сторону WebSocket а не в сторону Ajax

SELECT `phone`, count(`id`) as `count`
FROM `orders`
WHERE `accept` >= NOW() - INTERVAL 120 DAY AND `accept` <= NOW() - INTERVAL 30 DAY
GROUP BY `phone`
HAVING `count` >= 2

Пропишите этот запрос в скрипт и просто вызовите его по крону. Или описание задачи не полное?

Смотря как у Вас будет дальнейшая работа. Насколько видно в Вашем случае, это получается просто дополнительная роль у сущности user. Т.е. вносить магазины в users, в уже при наличии роли shop - уже подтягивать данные из доп таблицы shop. Соответственно у Вас не будут путаться сущности, и будут отдельно данные для shop не засоряющие общую картину users.
Что касается скорости работы, оптимальности и прочего - без указания всей картины сложно будет сказать. Золотой пули не существует.

У Вас по факту получается, что одна новость, это набор записей в БД. Если прибегать к 1-й нормальной форме, то получится что то вида
id | lang_id | title | text
Причем первичным ключом в этом случае выступает уже связка id + lang_id. При входящем запросе уже определяется язык, который нужен браузеру и просто ко всем значениям подставляется
WHERE `lang_id`='$lang_id'
Но тогда придется самостоятельно организовывать работу с AUTO_INCREMENT, поскольку уникальность уже идет на уровне id+lang_id