hx510b

Попробуйте добавить в конфиг файл mysql, например так:

[mysqld]
init_connect='SET collation_connection = utf8mb4_unicode_ci'
collation-server=utf8mb4_unicode_ci

Чтобы прокинуть конфиг во внутрь docker образа используйте опцию -v

-v /local/path/to/hosts/config/collation.conf:/etc/my.cnf.d/collation.conf

1. Убедиться, что для id есть индекс.
2. Возможно для поля views очень много индексов и они долго обновляются.
3. Слишком широкая таблица tbl_banner
3. Проверить нагрузку на сервере с БД - LA, нагрузка CPU, iowait - чем меньше значение - тем лучше.
LA<5..10, cpu < 100, iowait < 10...20
4. Жесткий диск работает "медленно" или неисправен.
5. Возможно, физический размер базы слишком велик и не помещается в буфер памяти. Это можно увидеть с помощью mysqltuner.pl
6. Возможно, что конфиг mysql не применяется - надо в этом убедиться.
Это типичные причины. Дальше надо смотреть конкретно.

Судя по:

Error in `/usr/sbin/mysqld': malloc(): memory corruption: 0x00007fcbfc124080

1. сделать копию /var/lib/mysql на другой накопитель

2. Исследуем и решаем:
2.1. вариант1 - битая память - прогнать memtest, может перегрев системы? устраняем или, если обе проблемы не подтверждаются, то идем дальше. Хотя тут похоже сторонний виртуальный сервер. Но проблема может быть.
Если проблема с ОЗУ, то протестировать внутри ОС можно созданием сжатых архивов и проверкой их целостности, в случае проблем с ОЗУ рано или поздно появятся ошибки контрольных сумм.

2.2. вариант2 - либо испорчены файлы данных, и mysql становится плохо из-за кривого кода. файлы могут быть испорчены некорректным завершением работы сервера либо проблемами с блочным устройством:

2018-08-20T05:10:47.359613Z 0 [ERROR] InnoDB: Could not find a valid tablespace file for `kubium/game`. Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting-datadict.html for how to resolve the issue.
2018-08-20T05:10:47.359626Z 0 [Warning] InnoDB: Ignoring tablespace `kubium/game` because it could not be opened.

- это может быть косвенным признаком проблем с файлами.
2.2.1. проверяем состояние блочных устройств smartctl - наличие offline uncorrectable или relocated sectos - могут быть причиной порчи данных - замена накопителя. Для чужого хостинга это недоступно. Можно косвенно проверить чтением блочного устройства /dev/vda
2.2.2. проверяем fsck файловую систему, наличие ошибок в файловой системы может указывать на повреждение содержания файлов БД. чиним и молимся, что важнейшие файлы не были задеты.
2.2.3. проверяем структуру innodb/myisam файлов, для этого используем штатные средства диагностики или вспомогательные утилиты, например "Percona Data Recovery Tool for InnoDB can help recover corrupted or deleted InnoDB tables. https://launchpad.net/percona-data-recovery-tool-f..." если проблемы - пытаемся чинить.
Простой старый способ решения некоторых проблем - это dump базы в sql файл , и импорт заново в базу. старую можно переименовать.
2.2.4. проблема может быть вызвана повреждением файлов индексов, в этом случае пересоздание индексов может все решить.

2.3. вариант3 - похожие проблемы могут наблюдаться при подсовывании двоичных файлов баз от более свежей версии mysql - проверяем эту версию.
Можно попробовать обновить версию mysql или сменить ее на mariadb, возможно некоторые проблемы уже решены.

На машине немного памяти - 1Гб, при исчерпании свободного ОЗУ в системе запускается OOM Killer, который убивает процессы в системе, вполне мог убить процесс mysql прямо посередине критичного изменения файлов БД. Это можно найти в логах.

Помимо предложений выше. Я бы по оптимизировал where
Условия простые и эффективные с точки зрения индексов подвинуть наверх, далее по возрастанию неэффективности.
Ведь при каждом новом условии объем выборки уменьшается, значит серверу придется делать меньше переборов
потом id in и id not in я бы свел к двум, это будет быстрее, чем несколько раз перекапывать выборку (особенно если она большая или вообще не лезет в память) для сравнения со списком. Т.е. сначала готовим списки, потом один раз сравниваем.
Конечно сам сервер должен быть оптимизирован под такие запросы, чтобы хватало выделенной памяти.