ilist implicit row lock in-memory database incremental backup index index cache  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.  A row lock that  InnoDB  acquires to ensure consistency, without you specifically requesting it. See Also row lock.  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.  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.  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.  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 . 6158