See Also C, Connector/C++. 

cache 

 The general term for any memory area that stores copies of data for frequent or high-speed retrieval. In InnoDB , the primary kind of cache structure is the buffer pool . See Also buffer, buffer pool. 

cardinality 

 The number of different values in a table column . When queries refer to columns that have an associated index , the cardinality of each column influences which access method is most efficient. For example, for a column with a unique constraint , the number of different values is equal to the number of rows in the table. If a table has a million rows but only 10 different values for a particular column, each value occurs (on average) 100,000 times. A query such as SELECT c1 FROM t1 WHERE c1 = 50;  thus might return 1 row or a huge number of rows, and the database server might process the query differently depending on the cardinality of c1 . 

If the values in a column have a very uneven distribution, the cardinality might not be a good way to determine the best query plan. For example, SELECT c1 FROM t1 WHERE c1 = x;  might return 1 row when x=50  and a million rows when x=30 . In such a case, you might need to use index hints  to pass along advice about which lookup method is more efficient for a particular query. 

Cardinality can also apply to the number of distinct values present in multiple columns, as in a composite index . See Also column, composite index, index, index hint, persistent statistics, random dive, selectivity, unique constraint. 

change buffer 

 A special data structure that records changes to pages  in secondary indexes . These values could result from SQL INSERT , UPDATE , or DELETE  statements ( DML ). The set of features involving the change buffer is known collectively as change buffering , consisting of insert buffering , delete buffering , and purge buffering . 

Changes are only recorded in the change buffer when the relevant page from the secondary index is not in the buffer pool . When the relevant index page is brought into the buffer pool while associated changes are still in the change buffer, the changes for that page are applied in the buffer pool ( merged ) using the data from the change buffer. Periodically, the purge  operation that runs during times when the system is mostly idle, or during a slow shutdown, writes the new index pages to disk. The purge operation can write the disk blocks for a series of index values more efficiently than if each value were written to disk immediately. 

Physically, the change buffer is part of the system tablespace , so that the index changes remain buffered across database restarts. The changes are only applied ( merged ) when the pages are brought into the buffer pool due to some other read operation. 

The kinds and amount of data stored in the change buffer are governed by the innodb_change_buffering and innodb_change_buffer_max_size  configuration options. To see information about the current data in the change buffer, issue the SHOW ENGINE INNODB STATUS  command. 

Formerly known as the insert buffer . 

See Also buffer pool, change buffering, delete buffering, DML, insert buffer, insert buffering, merge, page, purge, purge buffering, secondary index, system tablespace. 

change buffering 

 The general term for the features involving the change buffer , consisting of insert buffering , delete buffering , and purge buffering . Index changes resulting from SQL statements, which could normally involve random I/ O operations, are held back and performed periodically by a background thread . This sequence of operations can write the disk blocks for a series of index values more efficiently than if each value were written to disk immediately. Controlled by the innodb_change_buffering  and innodb_change_buffer_max_size configuration options. 

See Also change buffer, delete buffering, insert buffering, purge buffering. 

