Sorry Sergei i didn't read your email before sending more one... "Yes, my thought exactly. It'd be pretty easy to extend KILL to support killing by query_id, not by thread_id." some points that i think important... the "KILL [QUERY | CONNECTION] <thread_id>" is well know in mysql world, changing it to "KILL [QUERY | CONNETION] <query id>" will make some monitor softwares to not work anymode i think a new information to KILL is better, but since we have KILL [QUERY] option i think that QUERY keyword should be avoid.... KILL thread_id QUERY query_id, is nice since it easily tell what's the thread id, and it add a check before kill using query id, and don't add incompatibilty maybe a second command should be nicer if query_id is a "global" "auto increment" value, for example KILL QUERY_ID <query_id> or something compatible with the well know command "KILL [CONNECTION | QUERY] <thread_id>", maybe KILL [CONNECTION | QUERY] [<thread_id> | <thread_id> QUERY <query_id> | <thread_id> COMMAND <query_id> | COMMAND <query id>] ... well just a point of view ...