Deletion strategy not clearing indices for some mysql clients

[Fryie]

We switched from truncation to deletion for a project of ours because for some reason truncation was incredibly slow on some clients (apparently this has been observed before).

Unfortunately, on some machines this breaks the tests because mysql is complaining about a duplicate index. So to me this suggests that the indices are not reliably reset on all clients.
The behaviour seems particularly erratic:

• It works on my machine (Mac OS X Yosemite), on our CI server (I believe Debian or Ubuntu, although I'd have to check) and on a freshly set up Ubuntu VM
• But it doesn't work on a freshly set up Arch Linux VM (regardless of whether I use mariadb or the official Oracle mysql), nor on my coworker's Ubuntu machine.

However, the behaviour differs only across machines, it's consistent on one specific machine.

I suppose it must have something to do with specific mysql configuration options, but I'm at a loss as to what it could be in particular.
I realise this is not a precise problem description but maybe somebody around here has a clue?

Edit:
On a second look, it doesn't even appear to be consistent on a single machine. At least it works perfectly fine in the Arch Linux VM today. That's even weirder.

Edit2:
Works on Arch Linux with MySQL, but not mariadb, it seems.

[redross]

Have something similar.
When using DatabaseCleaner.clean_with(:deletion), some records are not deleted. Looking at why this happens I see that:
DatabaseCleaner::ActiveRecord::SelectiveTruncation#tables_with_new_rows tries to select which tables should be deleted. But since information_schema.tables table only has "estimates of row sizes" the query:

SELECT table_name
FROM information_schema.tables
WHERE table_schema = '#{@db_name}' AND table_rows > 0

doesn't return some tables that do have records (but their description in information_schema says they don't).

Not sure what can be done here. Explicit count strategy would probably be too slow?