If you have the
privilege, you can see all threads. If you have the
SUPER privilege, you can kill all
threads and statements. Otherwise, you can see and kill only
your own threads and statements.
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 BY loops, the flag
is checked after reading a block of rows. If the kill flag
is set, the statement is aborted.
ALTER TABLE, the kill
flag is checked before each block of rows are read from the
original table. If the kill flag was set, the statement is
aborted and the temporary table is deleted.
DELETE operations, 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. Note that if you are not using transactions, the
changes are not rolled back.
GET_LOCK() aborts and returns
INSERT DELAYED thread
quickly flushes (inserts) all rows it has in memory and then
If the thread is in the table lock handler (state:
Locked), the table lock is quickly
If the thread is waiting for free disk space in a write call, the write is aborted with a “disk full” error message.
Some threads might refuse to be killed. For example,
CHECK TABLE, and
OPTIMIZE TABLE cannot be
killed before MySQL 4.1 and run to completion. This is
REPAIR TABLE and
OPTIMIZE TABLE can be killed
as of MySQL 4.1.0, as can
TABLE as of MySQL 4.1.3. However, killing a
REPAIR TABLE or
OPTIMIZE TABLE operation on a
MyISAM table results in a table that
is corrupted and is unusable (reads and
writes to it fail) until you optimize or repair it again
CHECK TABLE finds a
problem for an
InnoDB table, the server
shuts down to prevent error propagation. Details of the
error will be written to the error log.