## ilist 

 Within an InnoDB FULLTEXT index , the data structure consisting of a document ID and positional information for a token (that is, a particular word). See Also FULLTEXT index. 

## implicit row lock 

 A row lock that InnoDB  acquires to ensure consistency, without you specifically requesting it. See Also row lock. 

## in-memory database 

 A type of database system that maintains data in memory, to avoid overhead due to disk I/O and translation between disk blocks and memory areas. Some in-memory databases sacrifice durability (the “D”  in the ACID design philosophy) and are vulnerable to hardware, power, and other types of failures, making them more suitable for read-only operations. Other in-memory databases do use durability mechanisms such as logging changes to disk or using non-volatile memory. 

MySQL features that address the same kinds of memory-intensive processing include the InnoDB buffer pool , adaptive hash index , and read-only transaction  optimization, the MEMORY  storage engine, the MyISAM  key cache, and the MySQL query cache. 

See Also ACID, adaptive hash index, buffer pool, disk-based, read-only transaction. 

## incremental backup 

 A type of hot backup , performed by the MySQL Enterprise Backup  product, that only saves data changed since some point in time. Having a full backup and a succession of incremental backups lets you reconstruct backup data over a long period, without the storage overhead of keeping several full backups on hand. You can restore the full backup and then apply each of the incremental backups in succession, or you can keep the full backup up-to-date by applying each incremental backup to it, then perform a single restore operation. 

The granularity of changed data is at the page  level. A page might actually cover more than one row. Each changed page is included in the backup. 

See Also hot backup, MySQL Enterprise Backup, page. 

## index 

 A data structure that provides a fast lookup capability for rows  of a table , typically by forming a tree structure ( B- tree)  representing all the values of a particular column  or set of columns. 

InnoDB  tables always have a clustered index  representing the primary key . They can also have one or more secondary indexes  defined on one or more columns. Depending on their structure, secondary indexes can be classified as partial , column , or composite  indexes. 

Indexes are a crucial aspect of query  performance. Database architects design tables, queries, and indexes to allow fast lookups for data needed by applications. The ideal database design uses a covering index  where practical; the query results are computed entirely from the index, without reading the actual table data. Each foreign key  constraint also requires an index, to efficiently check whether values exist in both the parent  and child  tables. 

Although a B-tree index is the most common, a different kind of data structure is used for hash indexes , as in the MEMORY  storage engine and the InnoDB adaptive hash index . R-tree  indexes are used for spatial indexing of multi-dimensional information. 

See Also adaptive hash index, B-tree, child table, clustered index, column index, composite index, covering index, foreign key, hash index, parent table, partial index, primary key, query, R-tree, row, secondary index, table. 

## index cache 

 A memory area that holds the token data for InnoDB full-text search . It buffers the data to minimize disk I/O when data is inserted or updated in columns that are part of a FULLTEXT index . The token data is written to disk when the index cache becomes full. Each InnoDB FULLTEXT  index has its own separate index cache, whose size is controlled by the configuration option innodb_ft_cache_size . 

