ThunderCat

Сейчас вроде бы все работает, но таймеры на клиентах игроков бывает уходят в минус.

Что мешает останавливать таймер в 0? Если ноль то автоматически считать что оппонент сделал/пропустил ход, на всякий случай принудительно проверит что на сервере произошло(ходил ли игрок) и передать ход.

RewriteRule !\.(js|ico|gif|jpg|png|css|pdf|mov|mp3|woff2)$ index.php

многие ко многим?

Это

<button class="center-block" id="but" onclick="game()">Крутить</button>

и это
but.addEventListener('click', function func() {
что за фигня? Зачем по клику создавать на этом же элементе листенер клика?

прочитать про формы?

$('#идкнопкипоиска').on('click',function(){
   $(#иднавбара).hide()
})

Оно?

записей в таблице products очень много ( около 1млн )

это не много, это нормально

и запросы типа JOIN не предлагать, так как оно существенно влияет на производительность

а этот бред вы как догадались сюда приплести? У вас наоборот с выходом из внутренних джоинов выборка по ид будет сокращаться, в итоге по таблице продуктс будет только джоин нужных ид(что аналогично выборке where in, только с меньшими ограничениями, например ордер и лимит). По этому сджойнте мелкие таблицы, получите с них модел_ид, и по нему уже джоин продкут.
Я бы денормализовал продуктс, внес бы еще брэнд_ид в него, но это так, мелочи.

TL;DR
прописать классу pointer-events: none;
в начале действа дать этот класс нужному элементу, по окончании убрать

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

это псевдоаттрибуты, в которые можно записать какое-то значение и потом использовать из яваскрипта, например из jquery можно получить значение data-mute-video примерно так:
var mute = $('#apps').data('mute-video');

я не в курсе кто такой gtag, но возможно не хватает preventDefault и форма делает и субмит и код.

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

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

Нет, это пользователи чисто бд, для этого в веб приложениях они не используются.

Информация об авторизации фиксируется не чьей стороне? При переходах со страницы на страницу каждый раз происходит переконнект к БД, а значит теряется информация о предыдущей сессии?

Не надо путать авторизацию пользователя на сайте и авторизацию скрипта при доступе к бд. Скрипт имеет единые настройки для подключения к бд, а пользователь взаимодействует со скриптом через вебсервер, напрямую к бд пользователь никак не может обратиться. При авторизации цепочка действий примерно следующая:
- вводим данные авторизации(браузер) и отправляем на сервер
- сервер принимает данные, создает соединение к бд, и проверяет запросом правильные ли данные ввел пользователь.
- Если все ок, создается запись в сессии(читайте про механизм сессий в пхп), и в дальнейшем проверяется при каждом запросе к серверу, есть ли соответствующий ключ в сессии. Если есть - значит пользователь авторизирован.

Если казино не шарага в подвале, то ни о каких заранее выигрышных для казино стратегиях речи быть не может, особенно если это сертифицированное заведение. Простая математика говорит нам о том, что если шанс у игрока хотя бы на 0,1% меньше шанса казино, в перспективе казино заберет все деньги игрока. Так что им не надо придумывать себе какие-то "особые" алгоритмы. Более того, все электронные казино ОБЯЗАНЫ иметь генератор случайных чисел с высокой долей приближения к "реальному" случайному распределению, и эти генераторы все имеют сертификацию государственного контроля. Ну и все игры в казино имеют "перекос" по шансам от ~51% до ~60%, в пользу казино разумеется.

Все очень просто - если это дата и/или время - использовать формат datetime, во всех остальных случаях соответствующие хранимым данным типы. Int для timestamp вообще непотребство в чистом виде.

Дату/время рождения - это DATETIME

У вас хранится время рождения? Тут можно использовать DATE, но я бы не скупился и поставил DATETIME из соображений единообразности работы с датой и временем.

формат 2 подходит, сообщение это 1 сущность, не надо разбивать ее на подсущности, это ускорит работу с таблицей и немного упростит миграции и репликации. Возможно аттачмент стоит вынести в отдельную таблицу, так как не факт что завтра их не будет больше 1. Не хватает статуса прочтен и статуса удалено у какого-то пользователя.
По количеству - таблица считается большой от нескольких миллионов записей, скорость выборки зависит от кучи параметров, как железа так и структуры индексов/данных.

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