KILL [CONNECTION | QUERY] processlist_id
Each connection to mysqld runs in a separate
thread. You can kill a thread with the
Thread processlist identifiers can be determined from the
ID column of the
PROCESSLIST table, the
Id column of
PROCESSLIST output, and the
PROCESSLIST_ID column of the Performance
threads table. The value for
the current thread is returned by the
KILL permits an optional
KILL QUERYterminates the statement the connection is currently executing, but leaves the connection itself intact.
The ability to see which threads are available to be killed
depends on the
The ability to kill threads and statements depends on the
You cannot use
KILL with the
Embedded MySQL Server library because the embedded server
merely runs inside the threads of the host application. It
does not create any connection threads of its own.
When you use
thread-specific kill flag is set for the thread. In most cases,
it might take some time for the thread to die because the kill
flag is checked only at specific intervals:
GROUP BYloops, the flag is checked after reading a block of rows. If the kill flag is set, the statement is aborted.
ALTER TABLEoperations that make a table copy check the kill flag periodically for each few copied rows read from the original table. If the kill flag was set, the statement is aborted and the temporary table is deleted.
KILLstatement returns without waiting for confirmation, but the kill flag check aborts the operation within a reasonably small amount of time. Aborting the operation to perform any necessary cleanup also takes some time.
DELETEoperations, the kill flag is checked after each block read and after each updated or deleted row. If the kill flag is set, the statement is aborted. If you are not using transactions, the changes are not rolled back.
GET_LOCK()aborts and returns
If the thread is in the table lock handler (state:
Locked), the table lock is quickly aborted.
If the thread is waiting for free disk space in a write call, the write is aborted with a “disk full” error message.