You’d be mainly looking in the “TRANSACTIONS” section, which lists all the threads currently in InnoDB. You’ll want to look for threads that are “RUNNING” and then look for references to locks and lock waits. Hard to say ahead of time what you’ll see, but you’ll likely know it when you see it.
You can set the transaction isolation level dynamically (set global tx_isolation = “READ-COMMITTED”), and then set it in your config (transaction-isolation = “READ-COMMITTED”) for when the server restarts. As for pros and cons, the MySQL manual has a pretty good write-up:
The main point is that any transaction isolation level looser than REPEATABLE-READ is no longer fully ACID compliant, so if the client needs to be fully ACID compliant then changing it to READ-COMMITTED is not an option. Aside from that, the application that is using MySQL on the backend needs to be smart enough to handle the change in isolation level. READ-COMMITTED is generally pretty safe because it only takes into account committed data, but it could still confuse some applications, so they would need to test their app for compatibility.
The overall idea of the transaction isolation level is to determine how a transaction handles changes in data that occur while the transaction is still open. In REPEATABLE-READ, any changes to data that occur from another transaction are not seen while the initial transaction is still running. With READ-COMMITTED, however, a running transaction can see changes to data from other transactions as long as those changes have been committed.