ThunderCat

У меня как бы все полные статьи как отдельный 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) Код кошмарный, во-первых зачем-то засунут в функцию, хотя этот код вряд ли будет использоваться дважды, во-вторых функция использует внутри себя глобальные переменные, что плохо. Почитайте про чистые функции. Про метод "проверки" переменных вообще нет слов, сплошь междометия...

это чисто примерный запрос, но т.к. я в sql полный профан, прошу объяснить что в нем неверного.

Подскажите как можно снизить нагрузку и увеличить скорость запросов при условии оптимизированного кода и запросов.

При условии оптимизированного кода и запросов нагрузка будет примерно никакой, так как у вас они судя по представленному explain ооочень далеки от "оптимизированных".

1) Нет смысла руками рвать соединение, при завершении скрипта коннект закроется автоматически. В вашем же случае весьма вероятна ситуация что коннект порвали зря и скрипт еще не отработал до конца.
2) Онлайн порядка 500-1000 чел.Для запаса я бы поднял количество соединений до 1/4 онлайна. Зависит конечно от специфики сайта, но иногда их реально не хватает если сервер с активным взаимодействием с бэкендом.
3) Для драйвера бд пишется враппер, не по тому что это модно или прям необходимо для работы, а как раз на такие случаи, в логику врапера пишется опциональное логирование запросов и сразу видно "кто где срал", сколько реально запросов бегает и что вообще происходит. Тогда можно что-то решать на уровне много/мало и куда что крутить. В частности, может оказаться что коннект происходит чаще чем вы думаете и вовсе не там где задумывалось...