values without requiring expensive index maintenance operations. If the fill factor is too low, the index consumes more space than needed, causing extra I/O overhead when reading the index. If the fill factor is too high, any update that increases the length of column values can cause extra I/O overhead for index maintenance. See Section 15.6.2.2, “The Physical Structure of an InnoDB Index”  for more information. See Also index, page.  This row format is used by the  MyISAM  storage engine, not by  InnoDB . If you create an  InnoDB  table with the option  ROW_FORMAT=FIXED  in MySQL 5.7.6 or earlier,  InnoDB  uses the  compact row format  instead, although the  FIXED  value might still show up in output such as  SHOW TABLE STATUS  reports. As of MySQL 5.7.7,  InnoDB  returns an error if  ROW_FORMAT=FIXED  is specified. See Also compact row format, row format.  To write changes to the database files, that had been buffered in a memory area or a temporary disk storage area. The  InnoDB  storage structures that are periodically flushed include the  redo log , the  undo log , and the buffer pool . Flushing can happen because a memory area becomes full and the system needs to free some space, because a  commit  operation means the changes from a transaction can be finalized, or because a  slow shutdown operation means that all outstanding work should be finalized. When it is not critical to flush all the buffered data at once,  InnoDB  can use a technique called  fuzzy checkpointing  to flush small batches of pages to spread out the I/O overhead. See Also buffer pool, commit, fuzzy checkpointing, redo log, slow shutdown, undo log.  An internal  InnoDB  data structure that tracks  dirty pages  in the  buffer pool : that is,  pages  that have been changed and need to be written back out to disk. This data structure is updated frequently by  InnoDB  internal mini-transactions , and so is protected by its own  mutex  to allow concurrent access to the buffer pool. See Also buffer pool, dirty page, LRU, mini-transaction, mutex, page, page cleaner.  A type of pointer relationship, between rows in separate  InnoDB  tables. The foreign key relationship is defined on one column in both the  parent table  and the  child table . In addition to enabling fast lookup of related information, foreign keys help to enforce  referential integrity , by preventing any of these pointers from becoming invalid as data is inserted, updated, and deleted. This enforcement mechanism is a type of  constraint . A row that points to another table cannot be inserted if the associated foreign key value does not exist in the other table. If a row is deleted or its foreign key value changed, and rows in another table point to that foreign key value, the foreign key can be set up to prevent the deletion, cause the corresponding column values in the other table to become  null , or automatically delete the corresponding rows in the other table. One of the stages in designing a  normalized  database is to identify data that is duplicated, separate that data into a new table, and set up a foreign key relationship so that the multiple tables can be queried like a single table, using a  join  operation. See Also child table, FOREIGN KEY constraint, join, normalized, NULL, parent table, referential integrity, relational.  The type of  constraint  that maintains database consistency through a  foreign key  relationship. Like other kinds of constraints, it can prevent data from being inserted or updated if data would become inconsistent; in this case, the inconsistency being prevented is between data in multiple tables. Alternatively, when a  DML  operation is performed,  FOREIGN KEY  constraints can cause data in  child rows  to be deleted, changed to different values, or set to  null , based on the  ON CASCADE  option specified when creating the foreign key. 6152 fixed row format flush flush list foreign key FOREIGN KEY constraint