What do the four transaction isolation levels do, and which one is MySQL's default?

Isolation levels decide how much of other people's uncommitted or in-flight work your transaction is allowed to see. From weakest to strongest:

• READ UNCOMMITTED — you can read another transaction's uncommitted changes. Those are dirty reads, and they may be rolled back out from under you. Almost never appropriate.
• READ COMMITTED — you only see committed data, but two identical reads inside one transaction can return different values because someone committed in between. This is the default in PostgreSQL and Oracle.
• REPEATABLE READ — MySQL's default with InnoDB. Your transaction takes a consistent snapshot at its first read, so the same query returns the same rows all the way through. InnoDB additionally uses gap locks so phantom rows are largely prevented too, which is stronger than the SQL standard requires.
• SERIALIZABLE — transactions behave as if they ran one after another. Correct, but the extra locking costs concurrency.

Note: A very common follow-up is why READ COMMITTED is often preferred for high-write workloads: it takes fewer gap locks and therefore deadlocks less.