ThunderCat

тут только один запрос на вставку, зачем тут 3 запроса?

В логах сервера ошибок нет.

Это говорит только о том что логирование не настроено

if ($aff_id && $parent_aff_id){
        global $wpdb; 
        $table = $wpdb->prefix . 'uap_relations';
        $sql = "INSERT INTO $table VALUES(NULL, %d, %d)";
var_dump([$aff_id, $parent_aff_id]);
var_dump($sql); exit(); //тут смотреть и думать
        $q = $wpdb->prepare($sql, [$aff_id, $parent_aff_id]); //здесь вроде массив должен быть
        $wpdb->query($q);
      }

Во первых посмотреть что в переменных, для этого есть вар_дамп.
Во вторых, если переменные не пустые, взять запрос, подставить руками значения и выполнить запрос из пхпмайадмин или из оболочки напрямую. Скорее всего какое-то поле является обязательным, но не входит в ваш запрос, либо первое поле (id?) не автоинкремент... В любом случае вы увидите ошибку.

по доке не пробовали?
UPD: https://serverfault.com/questions/51982/converting...
UPD2: емнип, вроде как все индексы и ключи надо убить, после этого сделать конвертацию и создать ключи / индексы, что серьезно ускорит процесс.

Я щас опять банальщину немного прогоню, но на будущее и в помощь:
1) Не надо использовать global, это плохо, это говорит о том, что вы что-то делаете не так, совсем не так, и скоро ваши проблемы усугубятся многократно. На этом этапе надо включить голову, подумать почему так вышло, и переделать, пока не слишком поздно и код не превратился в добротное гуано.

2) Пока вы учитесь и не можете "на глаз" прикинуть что и как работает и почему работает так, а не иначе - var_dump() - ваш рулевой, если что то не работает - начиная от точки отказа и назад к источнику по порядку - фигачете вардамп всего что движется. Так во первых вы найдете что не работает гораздо быстрее нежели на форумах или тут, а во вторых будете попутно делать для себя массу открытий, что все работает вовсе не так как вы думали и содержит не то что вы подразумевали.

Есть более продвинутые инструменты а ля xdebug, как созреете - можете на него переходить, это гораздо эффективнее. Но на первом этапе хватит и вардампа.

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

У меня как бы все полные статьи как отдельный html файл:

Жееесть....

Можно ли их адрес как нибудь седлать вместо id?

можно, но зачем? Для темы сайта - самое то, по-хакерски законспирированные ссылки...

Что нужно поменять в скрипте, чтобы бонус выдавался раз в 24 часа,
не зависимо от того зашел пользователь на сайт или нет.

Ваще ничего, тупо отсчитывать количество дней от начала вашего "аттракциона невиданной щедрости" и выдавать это количество как монеты. Можно показывать только тогда когда юзер за ними зашел, ну и в тот же момент вносить в бд )

Проверьте pid файл, если он есть его надо удалить.

1) как уже указал вам Кирилл Несмеянов - читайте про джоин, ин и вложенные запросы, задача как раз классическая на джоин и ин.
2) Абсолютно верно замечено John Didact - из бд вы ВСЕГДА получаете "плоские" данные, однако вы можете для себя их разделить префиксами в алиасах и обработать на стороне кода как удобно.
3) Большой запрос с множеством джоинов почти всегда лучше нескольких маленьких. Исключение - большие массивы текстовых/блоб полей, но и это обычно не критично, если выставить адекватные лимиты. Как минимум, преимущество в возможности удобного кеширования. Плюс время на открытие/закрытие соединения, плюс не надо гонять туда-сюда полученные данные несколько раз.

Сильно зависит.
Во первых на таблицы могут быть навешены внешние ключи, перенос данных в другую таблицу может "сломать" логику.

Во вторых, если таблица предполагает наличие реально большого объема, например > 1М записей, имеет смысл что-либо делать, в ином случае вынос в отдельную архивную таблицу мегапрофита не принесет.

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

select * from (
    (select * from `games`
where  date > now()
order by date desc)
union
(select * from `games`
where  date < now()
order by date )
              ) a
limit 0,50

Буду благодарен за любые мысли.

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

1) Проверить кодировку сервера (apache - AddDefaultCharset utf-8)
2) Проверить кодировку соединения с бд (должна соответствовать utf-8)
3) при подключении задать set names utf8