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 ...