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

Насколько я понял, вы храните список категорий в одном поле через запятую. Это изначально неверный подход, противоречащий 3 нормальной форме, кроме того больше приносящий вреда и гемора чем профита. Кажущаяся "простота" такого подхода (как видно из вашего примера) оборачивается проблемами как только нужно применить логику чуть сложнее "выбрал-показал". Скорее всего при такой структуре самым "хорошим" решением будут циклы с запросами, что само по себе уже кошмарный говнокод.

Как вариант решения конкретно этой задачи - можно так:

foreach ($posts as $post) {
    $postsCat[trim(explode(',', $post['category'])[0])][] = $post['alt_name'];
}
unset($posts);

1) $id видимо определен выше вызова функции, но как уже вам указали - область видимости внутри функции - локальная, все что не определено внутри тела функции для нее не существует, исключение - глобальные переменные.
2) Научитесь пользоваться дебаггером, например xdebug, или хотя бы используйте var_dump().
3) sql запросы СНАЧАЛА формируете в виде строки, затем передаете в вызов, тогда можно будет их вывести и посмотреть что с ними не так, подозреваю что в варианте который вы "поправили" проблема в отсутствии поля user_id которое скорее всего обязательное. Можно проверить напрямую введя этот запрос в консоль мускуля или через phpmyadmin.
4) Код кошмарный, во-первых зачем-то засунут в функцию, хотя этот код вряд ли будет использоваться дважды, во-вторых функция использует внутри себя глобальные переменные, что плохо. Почитайте про чистые функции. Про метод "проверки" переменных вообще нет слов, сплошь междометия...