at the same time. Typically, transactions with this isolation level only do queries, not insert, update, or delete operations. 

See Also ACID, dirty read, isolation level, locking, transaction. 

## read view 

 An internal snapshot used by the MVCC  mechanism of InnoDB . Certain transactions , depending on their isolation level , see the data values as they were at the time the transaction (or in some cases, the statement) started. Isolation levels that use a read view are REPEATABLE READ , READ COMMITTED , and READ UNCOMMITTED . 

See Also isolation level, MVCC, READ COMMITTED, READ UNCOMMITTED, REPEATABLE READ, transaction. 

## read-ahead 

 A type of I/O request that prefetches a group of pages  (an entire extent ) into the buffer pool  asynchronously, in case these pages are needed soon. The linear read-ahead technique prefetches all the pages of one extent based on access patterns for pages in the preceding extent. The random read-ahead technique prefetches all the pages for an extent once a certain number of pages from the same extent are in the buffer pool. Random read-ahead is not part of MySQL 5.5, but is re-introduced in MySQL 5.6 under the control of the innodb_random_read_ahead  configuration option. 

See Also buffer pool, extent, page. 

## read-only transaction 

 A type of transaction  that can be optimized for InnoDB  tables by eliminating some of the bookkeeping involved with creating a read view  for each transaction. Can only perform non-locking read  queries. It can be started explicitly with the syntax START TRANSACTION READ ONLY , or automatically under certain conditions. See Section 8.5.3, “Optimizing InnoDB Read-Only Transactions”  for details. See Also non-locking read, read view, transaction. 

## record lock 

 A lock on an index record. For example, SELECT c1 FROM t WHERE c1 = 10 FOR UPDATE;  prevents any other transaction from inserting, updating, or deleting rows where the value of t.c1  is 10. Contrast with gap lock and next-key lock . 

See Also gap lock, lock, next-key lock. 

## redo 

 The data, in units of records, recorded in the redo log  when DML statements make changes to InnoDB  tables. It is used during crash recovery  to correct data written by incomplete transactions . The ever-increasing LSN value represents the cumulative amount of redo data that has passed through the redo log. See Also crash recovery, DML, LSN, redo log, transaction. 

## redo log 

 A disk-based data structure used during crash recovery , to correct data written by incomplete transactions . During normal operation, it encodes requests to change InnoDB  table data, which result from SQL statements or low-level API calls through NoSQL interfaces. Modifications that did not finish updating the data files  before an unexpected shutdown  are replayed automatically. 

The redo log is physically represented as a set of files, typically named ib_logfile0  and ib_logfile1 . The data in the redo log is encoded in terms of records affected; this data is collectively referred to as redo . The passage of data through the redo logs is represented by the ever-increasing LSN  value. The original 4GB limit on maximum size for the redo log is raised to 512GB in MySQL 5.6.3. 

The disk layout of the redo log is influenced by the configuration options innodb_log_file_size , innodb_log_group_home_dir , and (rarely) innodb_log_files_in_group . The performance of redo log operations is also affected by the log buffer , which is controlled by the innodb_log_buffer_size configuration option. 

