Я использую MySQL 8.0.21 Из установщика сообщества MySQL на Windows 10 обновлено до версии 2004 и по какой-то причине, если я создаю событие в планировщике событий, который вызывает процедура один раз в секунду (независимо от того, что на самом деле делает этот SP, я объясню свой тестовый пример) - мой процессор достигает максимума, и когда я смотрю на активные соединения в MySQL Workbench, он складывает тонну рабочих потоков, которые останавливаются в состоянии «Открытие таблиц». Мой P C зависает, мне нужно отредактировать событие, которое нужно отключить, остановить процесс MySQL в диспетчере задач и снова запустить службу.
ТЕСТОВЫЙ СЛУЧАЙ
Во время настройки нового сервера я использовал все настройки по умолчанию, за исключением того, что я включил общий журнал и использую новое шифрование 8.0+ mysql_sha2_password (хотя я ИЗМЕНЯЮ ПОЛЬЗОВАТЕЛЯ на mysql_native_password для phpmyadmin, чтобы можно было вернуть это, честно говоря, я не уверен)
- Я создаю новую схему под названием «Test»
- Я создаю одну таблицу под названием «TestTable», в которой есть только один столбец с именем «column1» INT
- Затем я создаю хранимую процедуру «TestPro c», которая выполняет «SELECT COUNT (*) FROM TestTable;» Настраивает Priv., DEFINER :: Definer - root@localhost и читает SQL
- . И, наконец, я создаю событие под названием «TestEvent», которое выполняет «CALL TestPro c () s», повторяющееся каждые 1 / se c, сохранить при завершении, а определитель - root@localhost
- перезапустить сервер перед запуском события.
Кроме того, если я включаю событие или создаю его, он будет работать без проблем, важно отметить, что проблема начинается, когда планировщик событий остается включенным, а событие остается включенным, а затем сервер перезапускается из служб в диспетчере задач. Сразу же разъемы ЦП поднимаются до максимума, и активные соединения показывают, что потоки складываются в стек, но не завершаются. Приветствуются любые подсказки, я не нахожу фактических ошибок и не знаю, с чего больше начинать отладку. Я пробовал пропускать таблицы грантов (но, очевидно, это не оптимально и не сработало).
I did find a hint when reviewing the MySQL 8.0+ docs
"If a repeating event does not terminate within its scheduling interval, the result may be multiple instances of the event executing simultaneously. If this is undesirable, you should institute a mechanism to prevent simultaneous instances. For example, you could use the GET_LOCK() function, or row or table locking. " from
However, when analyzing there does not appear to be any locks, nor should I need to implement such manually just for this test case (or my actual program)
UPDATE
Up to this point, albeit a rather niche bug, I do believe that is exactly what this is, and I have posted it on MySQL bug forum. 
Reference post is here: Обмен стеков DBA - DDeathlonger