Как отменить выполнение запроса в phpmyadmin

Если оператор все еще работает, вы можете использовать KILL QUERY <thread_id> .

Если заявление завершено, но вы еще не совершили транзакцию, вы можете использовать ROLLBACK .

Если оператор завершен и транзакция уже совершена (или вы не начали транзакцию), то восстановите данные из последней резервной копии.

Также здесь приведены советы для предотвращения такого рода ситуаций в первую очередь:

• При написании DELETE или UPDATE сначала записывайте предложение WHERE, чтобы вы не забыли его.
• Проверьте предложение WHERE в инструкции SELECT, чтобы убедиться, что вы обновляете правильные строки.
• Если вы знаете, что вам нужно обновлять только одну строку, вы можете добавить LIMIT 1 в свой оператор UPDATE. Тогда, если, несмотря на использование вышеуказанных методов, у вас все еще есть ошибка, по крайней мере, будет затронута хотя бы одна строка, а не вся база данных.

Вы можете перейти на страницу «процессы» и нажать «kill»

если вы удалили что-то, то я не думаю, что он вернется, если у вас нет резервной копии. Я знаю, что в sql вы иногда можете уйти, будет вызов ROLLBACK, прежде чем вы присоединитесь к серии команд SQL, но только в транзакциях, и вам придется сначала запустите их (что phpMyAdmin не использует).

Если вам нужна возможность восстановить предыдущие данные до фиксированного обновления, вы можете реорганизовать свою базу данных с помощью триггеров обновления и удаления для хранения старых данных в таблице архива с текущей датой / временной меткой или (предпочтительно) значением идентификатора транзакции (и убедитесь, что вставки всегда сохраняют текущую дату / временную метку или значение идентификатора транзакции) … эффективно сохраняя всю историю всех изменений, внесенных в вашу базу данных. Опасайтесь, ваша база данных будет расти с невероятной скоростью … это только действительно решение для критически важных данных, где история имеет важное значение, потому что она требует больших усилий для реализации и требует много дорогого дискового пространства. Даже в этом случае он может стать очень сложным, если последующие обновления затронутых данных; и вам может понадобиться «потерять» их при возврате к предыдущей истории.

Я могу только думать о очень немногих системах, которые реализуют этот тип обслуживания истории … например, Oracle Financials или HR.

С другой стороны, есть несколько баз данных (я использовал для работы со старой DEC RDBMS), которая может поддерживать RUJ (Run Unit Journals), которые затем могут быть использованы для восстановления из резервной копии и до заданного времени / транзакции. Однако MySQL не относится к этой категории. Опять же, для этого требуется много дискового пространства, и это практично только при регулярном резервном копировании ваших данных, а процесс восстановления более сложный. MySQL (насколько мне известно) не поддерживает эту функцию.

Для большинства людей более практичный подход – это простое восстановление из резервной копии, возможно, за которым следует некоторое ручное восстановление. К сожалению, большинство людей в наши дни даже не берут резервные копии.

Боюсь, если вы уже совершили транзакцию, нет никакого способа «отменить» ее. Это один из основных принципов ACID. Если вы этого не сделали: просто сделайте rollback , и все в порядке.

Вам нужно будет восстановить данные из резервной копии – или если запрос запущен, попробуйте, что предложил Марк Байерс, используя kill query .