сохраняешь список идентификаторов для проверки а следующем шаге, проверка - если какой то id остался с прошлой проверки - считать этот запрос медленным
Что за ерунду Вы говорите... Id в выводе этой команды - это идентификатор соединения, никакого отношения к выполняемым запросам не имеющий. Соединение установлено - запись со своим Id появилась, и будет до тех пор, пока соединение не будет закрыто или разорвано. Вне зависимости от того, выполняются там какие-либо запросы или нет, медленные они или быстрые... а соединение event scheduler по вашей методике так и вовсе будет всегда в выводе, даже если ни одной event procedure нет.
Slow query log - это самый обычный текстовый файл, пополняемый в задницу. Так что организовать его чтение - вообще не проблема. Прочитал, подписался на изменения (если надо на лету уведомлять о новых записях - ну или сам опрашивай длину файла), и всё...
Два человека, работающие в институте, один сетевой администратор, второй руководит отделом менеджмента качества образования, ответили одинаково. Цитирую: "Это вообще о чём речь-то?".
andry33822,
Я верно понимаю, что в показанном скрипте в таблицу users_apikey заранее заносятся ключи, которые ни к кому не привязаны (в поле username пустая строка), и Вы хотите, чтобы при вставке юзера в таблицу users выбирался (по какому-то критерию или произвольно) один непривязанный ключ, и закреплялся за этим свежесозданным юзером присвоением значения в поле username?
Ну скажем так - формулировка не получилась... выложите CREATE TABLE обеих таблиц, исходные данные, которые имеются, и желаемое состояние таблиц после вставки.
Если есть бэкап структуры БД, соответствующий базе в образе, а версия сервера БД абсолютно та же - то процедура несложная. Создать пустую БД, извлечь файлы таблиц из образа, заменить пустые на полные (DISCARD + IMPORT TABLESPACE).
Если бэкапа структуры нет - всё сложнее. Остановить сервер БД, спрятать куда-нить весь каталог данных (basedir), на его место положить каталог из образа, запустить сервер, сделать бэкап нужной БД, остановить сервер, вернуть на место каталог данных, запустить сервер, развернуть бэкап.
Если же версия сервера не совпадает - то где-то установить сервер той же версии, и далее как описано выше.
Забудь про INSERT .. VALUES. Для условной вставки записей (да и для безусловной тоже) используй INSERT .. SELECT.
прошло времени с текущей даты 24 часа
??? Это что такое было? Текущая дата - она потому и текущая, что здесь и сейчас. Если от неё прошло 24 часа, то текущая стала на 24 часа больше. И, блин, равна текущей.
чтобы в БД не было такого nickname, который передаётся в $nickname
Для этого в структуре таблицы должен существовать уникальный индекс по этому полю. Тогда и INSERT IGNORE начнёт работать как требуется - чтобы INGORE, сервер должен знать, по какому признаку надо IGNORE.
А если в date в БД 03.05.2022, а текущая дата 04.05.2022
В какой именно записи? с тем же nickname? тогда уникальный индекс должен быть по двум полям.
Я бы скормил его MySQL прям как есть. А там разобрал его на части и разложил по таблицам. Сложность процедуры зависит от структуры файла, но в любом случае сомневаюсь, что будут проблемы.
Андрей Плюта, выложите:
CREATE TABLE таблиц (неважные для вопроса поля можно удалить)
INSERT INTO с примером данных (десяток записей, но чтобы все варианты присутствовали)
Требуемый результат с подробными пояснениями
Что за ерунду Вы говорите... Id в выводе этой команды - это идентификатор соединения, никакого отношения к выполняемым запросам не имеющий. Соединение установлено - запись со своим Id появилась, и будет до тех пор, пока соединение не будет закрыто или разорвано. Вне зависимости от того, выполняются там какие-либо запросы или нет, медленные они или быстрые... а соединение event scheduler по вашей методике так и вовсе будет всегда в выводе, даже если ни одной event procedure нет.