synthetic key system tablespace table T  An indexed column, typically a  primary key , where the values are assigned arbitrarily. Often done using an auto-increment  column. By treating the value as completely arbitrary, you can avoid overly restrictive rules and faulty application assumptions. For example, a numeric sequence representing employee numbers might have a gap if an employee was approved for hiring but never actually joined. Or employee number 100 might have a later hiring date than employee number 500, if they left the company and later rejoined. Numeric values also produce shorter values of predictable length. For example, storing numeric codes meaning “Road” , “Boulevard” , “Expressway” , and so on is more space-efficient than repeating those strings over and over. Also known as a  surrogate key . Contrast with  natural key . See Also auto-increment, natural key, primary key, surrogate key.  One or more data files ( ibdata files ) containing the metadata for  InnoDB -related objects, and the storage areas for the  change buffer , and the  doublewrite buffer . It may also contain table and index data for  InnoDB  tables if tables were created in the system tablespace instead of  file-per-table  or  general tablespaces . The data and metadata in the system tablespace apply to all  databases  in a MySQL  instance . Prior to MySQL 5.6.7, the default was to keep all  InnoDB  tables and indexes inside the system tablespace, often causing this file to become very large. Because the system tablespace never shrinks, storage problems could arise if large amounts of temporary data were loaded and then deleted. In MySQL 8.0, the default is  file-per- table  mode, where each table and its associated indexes are stored in a separate  .ibd file . This default makes it easier to use  InnoDB  features that rely on  DYNAMIC  and  COMPRESSED  row formats, such as table  compression , efficient storage of  off-page columns , and large index key prefixes. Keeping all table data in the system tablespace or in separate  .ibd  files has implications for storage management in general. The  MySQL Enterprise Backup  product might back up a small set of large files, or many smaller files. On systems with thousands of tables, the file system operations to process thousands of  .ibd files can cause bottlenecks. InnoDB  introduced general tablespaces in MySQL 5.7.6, which are also represented by  .ibd  files. General tablespaces are shared tablespaces created using  CREATE TABLESPACE  syntax. They can be created outside of the data directory, are capable of holding multiple tables, and support tables of all row formats. See Also change buffer, compression, data dictionary, database, doublewrite buffer, dynamic row format, file-per- table, general tablespace, .ibd file, ibdata file, innodb_file_per_table, instance, MySQL Enterprise Backup, off- page column, tablespace, undo log.  Each MySQL table is associated with a particular  storage engine .  InnoDB  tables have particular  physical  and logical  characteristics that affect performance,  scalability ,  backup , administration, and application development. In terms of file storage, an  InnoDB  table belongs to one of the following tablespace types: .ibd  data files contain both table and  index  data. InnoDB  tables created in file-per-table tablespaces can use  DYNAMIC  or  COMPRESSED  row format. These row formats enable  InnoDB  features such as  compression , efficient storage of  off-page columns , and large index key prefixes. General tablespaces support all row formats. •The shared  InnoDB system tablespace , which is comprised of one or more  ibdata files . •A  file-per-table  tablespace, comprised of an individual  .ibd file . •A shared  general tablespace , comprised of an individual  .ibd  file. General tablespaces were introduced in MySQL 5.7.6. 6191