InnoDB mysql database as the most commonly used storage engine, naturally contains a lot of its unique characteristics. As compared to all the more important characteristics of memory, MyISAM engine, InnoDB supports row-level locking, transactions, and so on.
This article will inventory the advanced features than the next InnoDB processing transactions and row-level locking
First, the adaptive hash
When indexing innodb only B + tree index can be established, is not create the hash index, and the hash index with respect to the B + tree index, although they can not achieve the sort, the range of search results, but when the equivalent retrieval mM no doubt the efficiency than the B + tree index is much higher.
So innodb on the basis of the B + tree index basis, but also adds adaptive hash index, but this index can not be created manually, by innodb storage engine at runtime to create their own, it is transparent to the user.
When Innodb monitors lookup table of the secondary index on the heap, if you find a secondary indexes frequently accessed, then that is the focus of this secondary index data, will create a hash index for this secondary index, and then retrieve it the next time It can be retrieved directly through the hash index.
innodb think the recent three consecutive secondary index is being accessed hot data, it will automatically create a hash index
Advantages and disadvantages of hash indexes are obvious:
Advantages are: many times more efficient than the equivalent query retrieves B + tree high retrieval efficiency; no maintenance man, innodb their own maintenance
The disadvantage is: will occupy part of the innodb buffer pool; only suitable equivalent queries, do not support range queries; only effective in extreme cases, if not continuously read the same index is invalid
Second, the buffer insert (insert buffer)
Insert cache is directed to non-clustered index terms, are generally clustered index as sequential, while executing a batch after it is inserted into the first insert statement is completed, the page data is located behind and substantially all a data in the same page or adjacent pages, according to the characteristics of the pre-read the database.
So when the bulk insert only need to load the page 1 to complete the insert pieces of data. But for non-clustered indexes indexes are basically disordered, discrete. So every time you need to insert discrete access to non-clustered index pages, apparently reduces the insertion of performance.
So Innodb order to solve this problem is to insert new caching capabilities for non-clustered indexes insert or update, the update is not directly to the index page, but the first judgment of non-clustered index update the existence of the buffer pool, if you directly into the pool; if there is no first into the buffer pool.
Then at some frequency data cache and buffer pool of non-clustered index page merge operation. Since a page index, it can often be combined into a plurality of insert operations, reduces the IO operations of the non-clustered index pages.
Insert buffer conditions:
1, the index must be non-clustered index (clustered index is ordered, no cache)
2, the index is not the only (only case would be meaningless, can only achieve the effect of delaying, not reduce the number of IO)
Insertion of cache disadvantage is the need for space portion of the buffer pool can be configured IBUF_POOL_SIZE_PRE_MAX_SIZE configuration, such as a value of 3, only the maximum buffer pool space 1/3
Third, the secondary write (double write)
double write mainly in order to enhance the reliability innodb ensure that data is not lost.
Is divided into two parts: a double write buffer memory, the size of 2M; is part of a shared space on the disk table (ibdata) in two successive zones, i.e. 128, the size is 2M
1, when the dirty pages trigger data buffer pool to refresh, is not written directly to disk files, but the first copy to the double write buffer in
2, and then written to disk in the shared space table (stored contiguously sequential write efficiency) in two portions from each double write buffer write 1M
3, when the second step is completed, and then double dirty page write data is written to Buffer tablespaces actual file (discrete write); dirty pages after the completion of the data may be marked persistence double data write area can be covered a.
Why double write:
1, the smallest unit on the IO, order is 8K, mysql is one that is 16K; the smallest unit of IO file system is 4K, while others 1K; the smallest unit of disk IO is 512 bytes
2, when the need to write dirty pages 16K of data to a disk file, assuming that each is 4k, then you need four times the physical disk write operation to complete brush.
3. If after performing physical writes twice, the system fails, it will cause the disk has been written in an incomplete data page (data page is broken)
4, system recovery, redo log can only add old, check the full page of data recovery a dirty block, can not repair broken data page, which can cause data inconsistencies (redo log record is the physical changes to the page )
double write crash recovery
If the operating system to write the page in the disk process downtime, recovery time can be found in the most recent copy of the page from the double write file-sharing table space, copy it to the table space file, and then through the redo log can be completed recovery operations.
So why you do not need to write the log by double write it? Because the log is written in units of 512 bytes, so there is no problem of data corruption.
So why not write directly from the double write data page of it?
Because the file is double write, and discrete data page is read from the double write data in the write data page is clearly not write data page directly from the cache is faster;
Fourth, the buffer pool (innodb buffer pool)
innodb maintains multiple buffer pool in memory for caching data and indexes recently visited. The main pool is arranged as follows:
innodb_buffer_pool_size: buffer pool size, arranged recommended 70% to 80% of the total system memory
innodb_buffer_pool_instance: The number of buffer pool, it is recommended to set the number of CPU cores
innodb_flush_log_at_trx_commit: how data buffer pool brush plate, set to 1, data is not lost; 2 is set to a maximum loss of 1 second, but higher performance (mysql service hung up without loss of data, loss of data only machine downtime)
Buffer pool memory management:
List by internal buffer pool management data, using the LRU algorithm (not recently visited) out of the data, when the buffer pool slowly, and will delete the data has not been recently accessed; when inserted buffer pool, it is not inserted List of head or tail, but the list is inserted into the intermediate
Because the data is a hot head, the tail is coming out of the data, using the insurance policy the new data into the middle quite reasonable. List stored in page units , so the insertions and deletions are based on page units.
LRU algorithm as a whole new list List of 5/8; 3/8 as the rest of the old list; old list is the potential of the data will be eliminated; if the old list of data to be accessed, will be inserted into the new list to the head
So innodb buffer pool operations are almost always achieved, load the data disk to buffer pool, then the next step, when the update is directly update data in the buffer pool, then press a certain frequency to refresh disk.
Another feature is the pool-ahead, pre-reading function is executed when an IO operation innodb loaded with one or more pages later, is expected to be the next time you need to load data into the page, and advance to load data into the buffer pool, IO operation will again be avoided under
Two algorithms pre-read prefetch points: pre-reading and random linear prefetch
Linear prefetch: page will be sequential prefetching, pre-read page number may be provided by configuring
Random Read Ahead: When a a a page (extent) or, after being loaded, the page will all the extent of a few pages are loaded into the buffer pool