Ипатьев

Можно, но код, который создает БД при ошибке - это глупость.
Так не делают.

Можно создать отдельный скрипт для настройки окружения, который создаст БД и таблицы например.
В этом скрипте просто не указывать 4-й параметр в mysqli_connect.
И дальше просто написать mysqli_query() c запросом создания таблицы.

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

Никак.
Собирать запрос через f-word и выполнять без параметров.

1. Вставить в первую
2. Вставить во вторую.

При возникновении ошибок - прочитать и исправить.

В запросе ничего сложного, всё так, как вы и описали
Только, разумеется, в одном запросе.

Для этого пора бы уже освоить джойны. Нормализацию БД вы освоили - это прекрасно.
Джойны - тоже не бином ньютона, это основа SQL. Второй запрос не нужен, всё делается в одном
Сначала выбираем фильмы по тегам

select f.* from sakila.category c
join sakila.film_category fc on fc.category_id = c.category_id
join sakila.film f on f.film_id = fc.film_id
where c.name in ('Action', 'Drama') 
group by f.film_id;

Если хотим добавить поиск по заголовку, то просто добавляем к этому же запросу еще условие во WHERE, and description like '%Drama%'
https://sqlize.online/sql/mysql57/8d7c91ad5f6cf415...

Правда на таких объемах LIKE делать не рекомендуется. Но если сейчас работает по всей базе, то по десятой части и подавно будет. Но в целом надо уже прикручивать внешний поисковый движок, ElasticSearch. Ну или хотя бы добавить полнотекстовый индекс по названию (и тексту тогда уж заодно) и искать в них через match...against

Делать Percona XtraBackup по крону на бою, и потом накатывать его на тест.
Остальное - от лукавого. "Через консоль" будет блокировать таблицы, что такое "через экспорт-импорт" непонятно что значит, а ивенты тут вообще не при делах.

mysqli_query() выполняет только один запрос.
если надо выполнить два, то надо вызвать эту функцию два раза

кодировка соединения должно выставляться не SQL запроса, с с помощью специальной функции.
SET GLOBAL на хостинге работать не будет

Если это не хайдлоад, то есть 95% всех случаев, то никакой проблемы и нет, альтеры отработают быстро.
В остальных случаях примерно такая схема и применяется, только непонятно, зачем всю базу-то гонять.
https://github.com/github/gh-ost
https://docs.percona.com/percona-toolkit/pt-online...

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

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

Нет разницы, один или 10.
Для простоты индекс можно рассматривать как отсортированный список.
Если список учеников в классном журнале отсортирован по алфавиту, то вы довольно быстро найдёте нужного.
А теперь представьте, что вы по тому же самому списку ищете фамилию, на зная первой буквы. И тут уже без разницы, сколько букв мы не знаем. И одной достаточно, чтобы полностью поломать поиск.

Точно такие же проблемы будут и у базы данных. Вместо отсортированного списка с выходом сразу на нужную букву, придётся тупо искать перебором.

Полнотекстовый индекс также не является чем-то особенным в этом плане. Он устроен по совершенно тупому принципу: грубо говоря, БД берёт текст из колонки, и разбивает его на слова. И строит по этим словам снова точно такой же отсортированный список, с указанием, в каких строках это слово используется. То есть когда мы делаем запрос с match, то mysql находит искомое слово в индексе, и возвращает из него все строки.

И точно так же полнотекстовый индекс не работает, если поставить звёздочку спереди. Мануал так и говорит:

Words match if they begin with the word preceding the * operator

То есть звездочка работает только если поставить её в конце слова.
match against ('класс*') найдёт слово "классный", а '*accный' его уже не найдёт.
То есть БД тебе сразу говорит, что для такого поиска полнотекстовый индекс будет бесполезен.

Вопрос сложный, это издержки разработки под виндоуз.
Весь мир давно уже работает с кодировкой utf-8, а эта допотопная система всё ещё выдаёт свои ошибки в 1251.

Я бы не стал делать никаких специальных телодвижений по перекодированию ошибок виндоус. На боевом сервере эта проблема будет неактуальной, а пару раз при разработке можно и потерпеть.
Как вариант - сделать запись ошибок в лог, и смотреть их каким-нибудь Блокнотом - он покажет нормально.
Ещё как вариант - не использовать опенсервер или чем вы там пользуетесь, а использовать встроенный сервер РНР - он перекодирует выводимые на экран ошибки в utf-8.

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