|
| 1 | +--- |
| 2 | +title: Transaction Mode |
| 3 | +--- |
| 4 | + |
| 5 | +<Note> |
| 6 | +Supported databases: MySQL, PostgreSQL, Oracle, SQL Server, TiDB, Redshift |
| 7 | +</Note> |
| 8 | + |
| 9 | +Bytebase provides transaction management to ensure safe database changes. By default, all SQL statements are wrapped in a transaction, allowing automatic rollback if errors occur during execution. |
| 10 | + |
| 11 | +## Enable/Disable Transactions |
| 12 | + |
| 13 | +When creating a plan, you can control whether SQL statements are executed within a transaction: |
| 14 | + |
| 15 | +- **Enabled (default)**: All statements run within a transaction boundary for safety |
| 16 | +- **Disabled**: Statements execute directly without transaction wrapping |
| 17 | + |
| 18 | + |
| 19 | + |
| 20 | +## MySQL-Specific Settings |
| 21 | + |
| 22 | +For MySQL databases, Bytebase offers additional control over transaction isolation levels to manage concurrent access and data consistency: |
| 23 | + |
| 24 | + |
| 25 | + |
| 26 | +### Available Isolation Levels |
| 27 | + |
| 28 | +- **READ UNCOMMITTED**: Lowest isolation, allows dirty reads |
| 29 | +- **READ COMMITTED**: Prevents dirty reads, allows non-repeatable reads |
| 30 | +- **REPEATABLE READ**: Default MySQL isolation, prevents dirty and non-repeatable reads |
| 31 | +- **SERIALIZABLE**: Highest isolation, prevents all phenomena but may impact performance |
| 32 | + |
| 33 | +## Best Practices |
| 34 | + |
| 35 | +- Keep transactions enabled for DDL and DML operations that modify data |
| 36 | +- Consider disabling transactions only for: |
| 37 | + - Large batch operations that manage their own transaction boundaries |
| 38 | + - Statements that cannot run within transactions (e.g., certain administrative commands) |
| 39 | +- Choose appropriate isolation levels based on your concurrency requirements and performance needs |
0 commit comments