Книга: Fedora™ Unleashed, 2008 edition
Data Locking
Data Locking
To prevent data corruption, a database needs to put a lock on data while it is being accessed. As long as the lock is on, no other process can access the data until the first process has released the lock. This means that any other processes trying to access the data have to wait until the current process completes. The next process in line then locks the data until it is finished, and the remaining processes have to wait their turn, and so on.
Of course, operations on a database generally complete quickly, so in environments with a small number of users simultaneously accessing the database, the locks are usually of such short duration that they do not cause any significant delays. However, in environments in which many people are accessing the database simultaneously, locking can create performance problems as people wait their turns to access the database.
Older versions of MySQL lock data at the table level, which can be considered a bottle neck for updates during periods of heavy access. This means that when someone writes a row of data in the table, the entire table is locked so that no one else can enter data. If your table has 500,000 rows (or records) in it, all 500,000 rows are locked any time 1 row is accessed. Once again, in environments with a relatively small number of simultaneous users, this doesn't cause serious performance problems because most operations complete so quickly that the lock time is extremely short. However, in environments in which many people are accessing the data simultaneously, MySQL's table-level locking can be a significant performance bottleneck.
PostgreSQL, on the other hand, locks data at the row level. In PostgreSQL, only the row currently being accessed is locked. The rest of the table can be accessed by other users. This row-level locking significantly reduces the performance impact of locking in environments that have a large number of simultaneous users. Therefore, as a general rule, PostgreSQL is better suited for high-load environments than MySQL.
The MySQL release bundled with Fedora gives you the choice of using tables with table- level or row-level locking. In MySQL terminology, MyISAM tables use table-level locking and InnoDB tables use row-level locking.
NOTE
MySQL's data locking methods are discussed in more depth at http://www.mysql.com/doc/en/Internal_locking.html.
You can find more information on PostgreSQL's locking at http://www.postgresql.org/docs/7.4/interactive/sql-lock.html.
- Choosing a Database: MySQL Versus PostgreSQL
- ACID Compliance in Transaction Processing to Protect Data Integrity
- 17.4.9. Runtime Control of Locking Mode
- Информация заголовочной страницы (Database header)
- Database dialect
- DATABASE CACHE SIZE
- Data sending and control session
- SCTP DATA chunk
- Data Binding Using the GridView Control
- Interbase DataPump
- GetDataBack
- Работа с DataRow