Ипатьев

Если отбросить все фантастические версии, типа различий между операционными системами Centos и Ubuntu, то ошибка Duplicate entry '1' for key 'cb_tmp_acc_buttons.PRIMARY' при явном указании значения автоинкрементного поля в запросе может быть вызвана двумя причинами:
1. в дампе дублируются значения id
2. после установки БД уже заполнена какими-то значениями.

Оба варианта легко проверить и исправить. В первом случае обращаться к авторам программы или поправить руками, во втором - сначала очистить базу.

С кавычками же - это однозначно к авторам этой кривой программы.

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

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

SELECT * FROM goods WHERE MATCH(name) AGAINST ('+выключатель +белый' IN BOOLEAN MODE);

найдёт таки все белые выключатели

Но встроенный в MySQL полнотекстовый поиск работает так себе и обычно пользуются внешними системами, Spinx Search или Elasticsearch

В Oracle Mysql/Percona теперь кэша запросов нет вообще. Потому что не нужно и вредно.
Вместо этого, при необходимости, точечно кэшировать отдельные запросы, на клиенте.
(Очевидные вещи, типа тюнинга конфигурации сервера и оптимизации запросов я здесь не упоминаю, они сами собой разумеются, и к кэшированию прямого отношения не имеют).

Ну или использовать MariaDB, там кэш пока ещё остался.

Это какой-то ужас.
Я не знаю, вопрос звучит как "Мне надо надеть штаны на голову и выйти погулять. Я думаю продеть в штанины руки, зайти в туалет, облиться холодной водой, высохнуть, надеть штаны на голову и идти гулять. Вот только боюсь простудиться, потому что вода холодная".

Весь этот кошмар происходит потому, что вы используете базу данных как микроскоп для колки орехов. Все проблемы тут оттого, что "это" сохраняется в одно поле в базе данных. А должно в разные. Так база данных устроена. Каждая частичка данных хранится в своем поле. Исключения бывают, но именно как исключения, а не как подход по умолчанию, и это явно не ваш случай.

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

Я имею в виду что должна это быть одна таблица, которая линкуется к текущей по связи один-ко-многим: таблица из трех колонок - id, user_id и собственно то значение, которое надо менять. Таким образом подмножество этой таблицы с одним и тем же user_id будет представлять из себя то самое "поле", которые вы пытаетесь редактировать сейчас. Но при этом все элементы будут лежать в отдельных строках, и редактироваться обычными SQL запросами.

Вопрос "почему не выводится" здесь неуместен. Здесь скорее подойдёт вопрос "Этот код вообще хоть как-то работает?" Спойлер: нет.

Этот код неправильный по стольким параметрам, что у меня просто нет слов.
Он писался явно без малейшего понимания, а просто методом "подставлю какой-то код, авось подойдёт".
Причём понимания нет ни на каком уровне - ни того как работает БД, ни того как работает РНР, ни того как РНР работает с БД. Ни даже простого житейского здравого смысла. Зачем в message_get() все эти $user_name = mysqli_real_escape_string ($username);?

Во-первых, с помощью LAST_INSERT_ID получить "последнюю запись" можно только сразу после вставки. А поскольку в "основном коде" получение сообщения явно не выполняется в одной ветке с записью, то LAST_INSERT_ID не сработает. Причём тут даже простой житейской логики нет. Если сначала один пользователь добавил сообщение, а потом второй, то при получении "последнего" как БД узнает, чьё "последнее" сообщение надо показать?
Чтобы показать последнее сообщение для определённого пользователя, надо, как правильно отметили в комментариях, надо отсортировать таблицу по времени добавления и выбрать только 1 строку с помощью LIMIT.
Но кроме этого надо указать, для какого пользователя мы получаем это сообщение.

Во-вторых, функция mysqli_real_escape_string() вызывается неправильно, она будет выдавать ошибку. А по-хорошему вообще нужно использовать не её, а подготовленные выражения.

В-третьих, 'message' в запросе вернёт слово 'message', а совсем не само сообщение.

В-четвёртых, view_message хочет показать несколько значений, но в запросе выбирается только это 'message'

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

function message_get($user_id) {
    global $db;
    $chat_id = mysqli_real_escape_string($db,$user_id);
    $query = "SELECT message_id, user_id as chat_id,  message as `text` 
        FROM `secret_messages` 
        WHERE user_id='$chat_id' ORDER BY id DESC LIMIT 1";
    $result = mysqli_query($db, $query);
    return $result->fetch_assoc();
}

и потом получать при вызове
$post = message_get($user_id);