Comment 8 for bug 1016272

Linux:
* mysql Ver 14.14 Distrib 5.5.41-37.0, for debian-linux-gnu (x86_64) using EditLine wrapper
* This is perl 5, version 18, subversion 2 (v5.18.2) built for x86_64-linux-gnu-thread-multi
* pt-kill 2.2.15

OSX:
* mysql Ver 14.14 Distrib 5.5.56, for osx10.11 (x86_64) using EditLine wrapper
* This is perl 5, version 18, subversion 2 (v5.18.2) built for darwin-thread-multi-2level
* pt-kill 3.0.2

Prep:
(echo 'create table foo (id integer);'; for x in {1..20000}; do echo 'INSERT INTO foo VALUES ('$x');'; done) | mysql $DBNAME

Then issue a prepared statement via your preferred method for doing that, e.g.:
SELECT a_id, b_id from (select a.id a_id, b.id b_id from foo a, foo b) c

The query takes a minute or more to run on my laptop (400M rows will do that!), which gives plenty of time for:
* This command to NOT find anything to kill: pt-kill --verbose --print --victims=all --busy-time 30
* This command to kill 'Execute'ing prepared statements on-sight, ignoring busy-time: pt-kill --verbose --print --victims=all --busy-time 30 --match-command 'Query|Execute'

In production we are getting this due to an Elixir app (using Ecto, using MariaEx) which very strongly prefers to use server-prepared statements. It looks like it's not hard to reproduce the 'Execute' state using Perl though (first time I've written perl in YEARS!):

#!/usr/bin/perl

use DBI;
my $dbh = DBI->connect('DBI:mysql:database=YOURDATABASE;host=127.0.0.1;mysql_server_prepare=1', 'USERNAME', 'PASSWORD')
          or die "Couldn't connect to database: " . DBI->errstr;

my $sth = $dbh->prepare('SELECT COUNT(*) FROM (SELECT a.id AS a_id, b.id AS b_id FROM foo AS a, foo AS b) AS c')
          or die "Couldn't prepare statement: " . $dbh->errstr;

$sth->execute()
      or die "Couldn't execute statement: " . $sth->errstr;