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.  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.  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.  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.  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.  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.  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. read view read-ahead read-only transaction record lock redo redo log 6180