Do chop up DELETEs. Both InnoDB and MyISAM suffer from sluggish DELETEs. Here are some of the reasons; and they are valid...
MyISAM locks the entire table while it is doing any write statement (eg, DELETE), so that can be another factor is deciding on the engine. This means that SELECTs and other queries must wait for the DELETE to finish. Chopping up limits the LOCK time.
PARTITION and MERGE are good ways for dealing with a table where you delete rows over, say, 30 days old, and new rows are continually coming it. Splitting the data by day (and having 30 of them in this case) into 'subtables'. You run a job once a day that "instantly" drops the oldest subtable and adds a new subtable. Most regular operation are unaware that the "table" they are accessing is really composed of 30 subtables.
Back to your situation -- innodb_buffer_pool_size should be somewhere around 29GB on a MySQL-only, InnoDB-only machine with 32GB of RAM. But...
How many secondary indexes do you have? Each of them need fiddling with for each row deleted. Sure, the PRIMARY KEY and the data are "clustered", so effectively it can do a block's worth (16KB) at a time, but the secondary keys (and worse yet, any CASCADING DELETEs!) hit other blocks, hence take time. Each of these is effectively:
1. read a block (unless it is in the buffer pool)
2. modify the block
3. write the block (eventually)
Now, let's look at low level disk I/O. RAID? BBWC? Plain 'ole cheap disk? What are the settings of
innodb doublewrite ON
innodb flush log at trx commit 0
innodb flush method O_DIRECT
All these can have a big impact on InnoDB read/write performance. Note: Although writes are delayed, they eventually have to happen; in big DELETEs, you can get to the point of saturating the I/O system with writes.
* doublewrite is good for assuring ACID, but it involves one(?) extra disk hit per transaction.
* trx also has to do with ACID, and in the extreme case, one of the values limits you to about 60 reads or writes per seconds on plain disks. That doesn't allow for very many rows to be deleted/sec if there are a lot of secondary indexes.
* O_DIRECT is advised for RAID with BBWC because writes are virtually instantaneous (until you get saturated).
Information overload?