MySQL raises Error 1317 (ER_QUERY_INTERRUPTED) when the server cancels a running statement, typically after a KILL command, timeout, deadlock, or shutdown.
MySQL Error 1317: ER_QUERY_INTERRUPTED occurs when the server stops a running statement, usually because of a KILL command, timeout, deadlock, or shutdown. Identify the trigger with SHOW PROCESSLIST, raise max_execution_time or optimize the query, then rerun inside a transaction to solve it.
Query execution was interrupted
MySQL Error 1317 with SQLSTATE 70100 means the server forcibly stopped a running statement before completion. The official message is "Query execution was interrupted". The interruption can come from a KILL command, timeout, deadlock handling, server shutdown, or resource limits.
The error surfaces at runtime, after parsing succeeds and execution has already begun. Because the server aborts mid-execution, partial data changes may or may not be committed depending on transaction isolation. Fixing the root cause quickly avoids lost work and blocked sessions.
User-initiated KILL QUERY or KILL CONNECTION commands immediately halt the target thread and raise Error 1317. Many GUI tools provide a Stop button that issues the same command.
Long-running statements can exceed the global or session variable max_execution_time, producing an automatic interrupt.
Row-level deadlock resolution may choose the current session as the victim, rolling back the statement and returning ER_QUERY_INTERRUPTED.
Server shutdown, replication failover, or operating-system signals can abort in-flight queries and surface the same error.
Resource exhaustion such as out-of-memory conditions or disk full can trigger an internal interrupt to protect the server.
Identify which mechanism stopped the query by examining the error log, SHOW PROCESSLIST output, and relevant status variables. Confirm whether a human issued a KILL command or an automated timeout fired.
If the query exceeded max_execution_time, increase the limit or optimize the SQL to finish sooner. Index tuning, rewrite of sub-queries, and LIMIT usage usually help.
When deadlock handling is to blame, review InnoDB status to locate conflicting transactions and redesign lock order or add appropriate indexes.
For server shutdown interruptions, restart MySQL and re-run the statement inside a transaction to ensure idempotency.
Analytics queries scanning huge tables often hit timeouts. Add composite indexes and filter on selective columns to finish within limits.
Background jobs that bulk delete old data may be killed during deploys. Wrap DELETE statements in small batches and resume automatically on failure.
ETL pipelines sometimes clash on the same row set and deadlock. Process tables in consistent order or use SELECT ... FOR UPDATE SKIP LOCKED to avoid waits.
Set realistic max_execution_time thresholds per session rather than globally to avoid unintended kills.
Use EXPLAIN and optimizer hints in Galaxy's SQL editor to profile execution plans before running heavy statements in production.
Implement query cancellation hooks in application code so users can safely retry aborted operations.
Monitor information_schema.processlist in Galaxy dashboards and alert when a query nears its timeout.
MySQL Error 1205 Lock wait timeout exceeded appears when a query waits too long for a lock rather than being killed outright.
Error 1213 Deadlock found when trying to get lock signals a deadlock that may also pick your session as the victim.
Error 3024 Query exceeded max_execution_time occurs when the optimizer aborts before execution, compared to 1317 which aborts during execution.
A user, script, or admin tool explicitly terminated the running statement, immediately raising Error 1317.
The statement ran longer than the configured time limit, and the server interrupted it automatically.
InnoDB chose the current session as the deadlock victim and interrupted the query to resolve the cycle.
A planned or unplanned shutdown ended all active sessions, interrupting in-flight statements.
Out-of-memory, disk full, or similar limits forced MySQL to stop the query for stability.
Raised when a statement waits longer than innodb_lock_wait_timeout for a lock to be released.
Indicates the server detected a deadlock and rolled back the victim transaction.
Thrown by the optimizer when the estimated plan surpasses the allowed execution time before it starts running.
If the statement is inside an explicit transaction, MySQL rolls back only that statement. You still need COMMIT or ROLLBACK to finish the rest.
Yes. Use SET SESSION or GLOBAL max_execution_time to adjust the limit instantly for new statements.
Dump utilities like mysqldump may be killed by watchdog scripts that terminate long queries. Exclude backup threads from such rules or raise their timeout settings.
Galaxy's SQL editor shows live execution stats and AI-driven query plans so you can optimize or cancel statements before they hit server timeouts.
.avif)
.avif){kind=logo}
