Warnings: Why are statements with limit clause unsafe even if there isn't a limit?

Question

I'm a bit irritated because of some warnings in mysql errorlog. Example 1:

[Warning] Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. 
The statement is unsafe because it uses a LIMIT clause. 
This is unsafe because the set of rows included cannot be predicted. 
Statement: UPDATE `table` SET `status` = '1' WHERE `ID` = '15800' LIMIT 1

My colleague wrote these statements and I always wondered about the purpose of limiting a statement while using explicit ID. Nonetheless, this warning also occurs by not using LIMIT.
Example 2:

[Warning] Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. 
The statement is unsafe because it uses a LIMIT clause. 
This is unsafe because the set of rows included cannot be predicted. 
Statement: DELETE FROM table WHERE id = 426888

What could be wrong in this case?

Answer 1

You have LIMIT without ORDER BY. Therefore, it is meaningless.

Sets do not have implied orders without ORDER BY. The error message tells you this:

This is unsafe because the set of rows included cannot be predicted

Does your DELETE have a trigger or such with a LIMIT?

Answer 2

What scares me about this question is that MySQL does not report a problem at the trigger level in the error. I wrote about this problem before back on Jan 06, 2012 : Has anyone ran into this replication breaking bug before?

I wrote in that past post that the bug report shows that as of Dec 10, 2010, there was a problem with trigger level issues not showing up in the error log while the reported problem would appear to be the original SQL. In your case, you see DELETE FROM table WHERE id = 426888 and just scratch your head, asking "how in the world would such a straightforward DELETE statement be deemed unsafe"?

MORAL OF THE STORY

@gbn's answer helped you realize that you needed to look to your trigger (+1 for @gbn). I wanted to reveal further how MySQL dropped the ball in not properly logging errors from the trigger level.