AUser0

То есть у вас единственный затык - "исчезновение" данных из файлов? Которое по факту оказывается и не исчезновением, потому что данные на месте? Тогда не мучайтесь с адаптацией в БД, однако решайте вопрос с "ложным исчезновением" данных.

P.S. Хотя бы проверьте, что блокировка действительно блокирует.

Ну сделайте
if(empty($user) or count($user) == 0) {

Переменная $user не определена внутри функции addUser(), в момент первого использования конечно. Кстати, это ошибка, PHP должен был об этом настойчиво сообщить.

Вообще-то пользовательских настроек у mysqld_safe нет, для запуска сервера они не используются.
И настройки именно сервера обычно хранятся в /etc/my.cnf. При ручном запуске mysqld_safe можно указать свой my.cnf.

Настройки пользователя лежат в директории пользователя ~/.my.cnf, и как правило настраивают подключение mysql-клиента к mysqld-серверу. На работу сервера они НЕ ВЛИЯЮТ, они влияют на подключение к серверу.

Вообще-то вариант
.... cp.path_id = '13' AND pf.text IN ('9', '4')
совершенно корректен, и равнозначен этому:

.... cp.path_id = '13' AND (pf.text = '9' OR pf.text = '4')

Наипростейший наитупейший, но рабочий вариант:

SELECT serial.serial_name, genre.genre_name
FROM serial
LEFT JOIN serial_genre ON serial_genre.serial_id = serial.serial_id
LEFT JOIN genre ON genre.genre_id = serial_genre.genre_id

У вас на главной странице ведь не происходит вызова (исполнения) файла page.php с данными $_GET['id']="343r";? Следовательно и HTML модального окна не генерируется, этот HTML нигде не выводится, и на главной странице этого HTML просто нет.

Вердикт: поэтому модальное окно с этим HTML на главной странице показать - НЕ-ВОЗ-МОЖ-НО, сколько ни тыкай по ссылке "Контакты"...

Так согласно условию в WHERE вам не должно показывать пользователя, у которого date_end заполнено. Вот база и не показывает. Что вы ещё от неё хотите? Что-бы она показала то, что не должна показать?

P.S. Кстати, у вас есть ошибочное понимание.

Когда значений в таблице user_rank нет вообще (по умолчанию значения 'Null')

Когда записи в таблице нет вообще - база на любой столбец записи из user_rank будет говорить, что он null. То есть и столбец `id` будет null, и столбец `id_user`, и `id_rank`, и `date_start`, и `date_end`. Независимо от их значений по умолчанию (null или что-то еще). Таково поведение MySQL при JOIN отсутствующей записи.

Так посмотрите, используется-ли вообще индекс при выполнении UPDATE запроса:

EXPLAIN UPDATE `users_statistics` SET `profit_ref_1`=`profit_ref_1`+'0.0021' WHERE `id_user`='1410' LIMIT 1;

в PhpMyAdmin, например. Или в консоли.

Правда такой запрос вернёт 3 записи, с разными type_id.
И общее кол-во нужно будет суммировать самостоятельно из этих 3-х записей.

SELECT COUNT(*) AS cnt, type_id
FROM example
WHERE user_id = 53 AND status = 1
GROUP BY type_id

Через SET NAMES вы указываете, какой кодировкой "обладают" данные, передаваемые MySQL-ю.
Если ваш сайт показывает (а значит и принимает) данные в кодировке CP1251 - тогда да, такой SET NAMES оправдан.
Если же на сайте странички в UTF-8 - тогда вы врёте MySQL-ю, что у вас данные в CP1251, ведь они в UTF-8.

P.S. Что у вас сайт в CP866 или в KOI-8, даже и предполагать не буду...

Как-то нелогично использование -1/+1, ведь дата начала означает, что в момент начала аудитория УЖЕ недоступна (занята).

Select * From date d where d.id not in(
SELECT d.id FROM date d, reservation r WHERE d.id BETWEEN r.datestart_id and r.dateend_id)

Вот так выдаёт действительно незанятые временные промежутки.

SELECT drop.name, MIN(drop_sell.price) AS min_price, MAX(drop_buy.price) AS max_price
FROM drop
LEFT JOIN drop_sell ON (drop_sell.drop_id=drop.id)
LEFT JOIN drop_buy ON (drop_buy.drop_id=drop.id)
WHERE drop.name='name'
GROUP BY drop.id

Так сделайте EXPLAIN этого запроса, и там скорее всего увидите, что в `range` и/или в `goods` нет записей, удовлетворяющих прописанным в JOIN параметрам.