1. What kind of situation is "a single SQL statement is rolled back as a result of an error" referring to?

from InnoDB Error Handling

If you run out of file space in the tablespace, a MySQL Table is full error occurs and InnoDB rolls back the SQL statement.

A lock wait timeout causes InnoDB to roll back only the single statement that was waiting for the lock and encountered the timeout.

A duplicate-key error rolls back the SQL statement

A row too long error rolls back the SQL statement

Does autocommit=1 count?

from 14.6.8. The InnoDB Transaction Model and Locking

In InnoDB, all user activity occurs inside a transaction. If autocommit mode is enabled, each SQL statement forms a single transaction on its own. By default, MySQL starts the session for each new connection with autocommit enabled, so MySQL does a commit after each SQL statement if that statement did not return an error. If a statement returns an error, the commit or rollback behavior depends on the error. See Section 14.6.12, “InnoDB Error Handling”.

From this I deduce: if autocommit is enabled then the transaction is not rolled back if “InnoDB Error Handling” says that only the statement is rolled back. But I am not sure if my interpretation is correct.

Any example?

If you start a transation and issue two update statements and the second one fails because of a Table is full error then the locks by the second update statement are not released after the error until the transaction is commited or rolle back, The locks of the first statement aren't released too until the transaction ist commited or rolled back.

2. I could imagine that if this happens, it leaves a lock to the rows affected and make any subsequent update to these rows fail, until a mysql restart or something that clears the lock, is that so?

All locks of your transaction are released after commiting or roling back the transaction. It is not necessary to restart the database. the update of the rows in the same transaction should not fail if you issue another update statement for this row because they are locked by you from the failing sql statement in the same transaction

1. What kind of situation is "a single SQL statement is rolled back as a result of an error" referring to?

from InnoDB Error Handling

If you run out of file space in the tablespace, a MySQL Table is full error occurs and InnoDB rolls back the SQL statement.

A lock wait timeout causes InnoDB to roll back only the single statement that was waiting for the lock and encountered the timeout.

A duplicate-key error rolls back the SQL statement

A row too long error rolls back the SQL statement

Does autocommit=1 count?

from 14.6.8. The InnoDB Transaction Model and Locking

In InnoDB, all user activity occurs inside a transaction. If autocommit mode is enabled, each SQL statement forms a single transaction on its own. By default, MySQL starts the session for each new connection with autocommit enabled, so MySQL does a commit after each SQL statement if that statement did not return an error. If a statement returns an error, the commit or rollback behavior depends on the error. See Section 14.6.12, “InnoDB Error Handling”.

From this I deduce: if autocommit is enabled then the transaction is not rolled back if “InnoDB Error Handling” says that only the statement is rolled back. But I am not sure if my interpretation is correct.

Any example?

If you start a transation and issue two update statements and the second one fails because of a Table is full error then the locks by the second update statement are not released after the error until the transaction is commited or rolle back, The locks of the first statement aren't released too until the transaction ist commited or rolled back.

2. I could imagine that if this happens, it leaves a lock to the rows affected and make any subsequent update to these rows fail, until a mysql restart or something that clears the lock, is that so?

All locks of your transaction are released after commiting or roling back the transaction. It is not necessary to restart the database. the update of the rows in the same transaction should not fail if you issue another update statement for this row because they are locked by you from the failing sql statement in the same transaction