Ипатьев

Данная ошибка может возникать в двух случаях:
- если вы обращаетесь к этому скрипту напрямую, а не как к обработчику формы
- если в форме были ошибки, и она тупо не передаёт поля login и pass методом POST.

Чтобы исправить первый вариант, и вообще для порядка, надо добавить проверку на метод POST.
Чтобы получить помощь для второго варианта, надо догадаться добавить в свой вопрос код формы.

В целом же, эта авторизация будет бессмысленной, даже когда заработает. Поскольку любой придурок легко авторизуется без пароля, тупо через SQL инъекцию. Очердной пример того, что учить программирование "по видео из интернета" - это пустая трата времени

Тут проблема скорее не в том, что 4-5 лет, а в том, что за редчайшими исключениями, любые видеокурсы - это отборный говнокод. Конкретно про Дмитрия Лаврика не скажу, но простая статистика говорит о том, что учить РНР по видеокурсам не стоит.

Лучше потратьтесь на книжку, Джон Дакетт, PHP&MySQL. Там очень толково, на примерах даётся не только язык, но и все важные аспекты программирования - обработка ошибок, отладка, рефакторинг, структура приложения, SQL, обработка изображений, и куча всего остального. В последних главах весь материал даётся на примере создания простой но рабочей социальной сети.

Первый уровень оптимизации запросов - это, разумеется, индексы.

Но иногда даже если все нужные индексы есть, база тупит неимоверно. В этом случае надо сразу смотреть значение innodb_buffer_pool_size. По умолчанию значение этого параметра всего 128 мегабайт. А это, грубо говоря, максимальное значение памяти, доступное MySQL для работы.

Собственно, суть работы индекса в том, что это упорядоченные данные, лежащие в оперативной памяти, за счёт чего процессор находит нужные данные очень быстро. Но вот если памяти тупо не хватает чтобы индекс в ней поместился, то его эффективность тут же превращается в тыкву.
При этом Mysql дисциплинированно не забирает всю доступную на компьютере память, а берет столько, сколько ей скажут. И если это значение не увеличить, то на большой базе индексы не поместятся в память и всё встанет колом, поскольку индекс будет читаться частями с диска, потом еще надо будет выбранные результаты свопить на диск, потом ещё сортировать полученный результат опять же на диске...

Разумеется, у mysql есть просто миллион разных настроек, которые тоже влияют на производительность. У Перконы, кажется, даже есть калькулятор, в который ты заливаешь информацию о своей базе, а он тебе выдаёт значения параметров конфигурации. Но это уже такая тонкая настройка, третий уровень. Ничего из этого не будет работать, если innodb_buffer_pool_size недостаточного размера. И его размер рекомендуется выставлять на максимально допустимое значение. Если это выделенный mysql сервер, то 80-90% от физической памяти. Если не выделенный - то столько, сколько не жалко, чтобы не мешать остальным приложениям.

Почему не работает Cron?

Наверное, вместо бессмысленного /dev/null надо указать путь к файлу, в котором появится ответ на этот вопрос?

Нет, неверно.

character-set-server и collation-server вообще ни на что не влияют. А только задают умолчания, если при создании БД и таблиц ленивый программист не указал кодировку. Поэтому трогать их нет смысла вообще.

Добавлять utf8mb4 в соединение также бессмысленно, если сами данные в utf8. Расширенные символы она всё равно сохранить не сможет.
И наоборот - если таблицы в utf8mb4, то указывать её при соединении надо в обязательном порядке. Не потому что вдруг "конвертация на лету" а потому что если соединение будет utf8, то расширенные символы клиент не получит.

(В теории, всё может работать нормально и без установки utf8mb4 для соединения, поскольку она в пыхе в какой-то момент начала использоваться по умолчанию, но лучше всё-таки задавать явно)

Это поговорка "В огороде бузина, а в Киеве дядька" по-айтишному.

• Microsoft SQL Server - это сервер. То есть программа, которая постоянно висит в памяти и принимает запросы от клиентов. Условно говоря - то, что и называется базой данных. Ну или точнее - СУБД, системой управления базами данных
  
• MySQL workbench и phpMyAdmin - это клиенты, то есть программы, которые могут посылать запросы на сервер. Но на Microsoft SQL Server они посылать запросы не могут, потому что работают с другим сервером - MySQL.
  
• при этом отличия между MySQL workbench и phpMyAdmin минимальные - обе являются графическими клиентами для СУБД MySQL, позволяя администрировать базу данных, редактировать таблицы в визуальном редакторе и выполнять SQL запросы. Только первое это десктопная программа, а второе - убогий веб-интерфейс, которому для работы нужен веб-сервер. И вместо которого всегда надо использовать нормальный клиент, например DataGrip, ну или хотя бы тот же Workbench.
  

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

elena@192.168.1.100 (ну или там elena@example.com)

Загрузите сохранённое соединение и отредактируйте поле с хостом, либо убрав имя с собакой совсем (и тогда удалённый сервер будет каждый раз запрашивать логин), либо вписав другое имя (и тогда в дальнейшем будет подставляться уже оно).

Ну или как вариант - нажмите Load и потом Delete - чтобы совсем удалить соединение и создать его заново.

А тот accept, который вы нажали - он про другое. Это отпечаток сервера, который путти сохраняет чтобы отличать подделки. Но когда соединение происходит в первый раз, это окошко тоже показывается.