CREATE TABLE Statement If you want to insert data into a  MERGE  table, you must specify with  INSERT_METHOD  the table into which the row should be inserted.  INSERT_METHOD  is an option useful for  MERGE  tables only. Use a value of  FIRST  or  LAST  to have inserts go to the first or last table, or a value of  NO  to prevent inserts. See Section 16.7, “The MERGE Storage Engine” . For  MyISAM  tables,  KEY_BLOCK_SIZE  optionally specifies the size in bytes to use for index key blocks. The value is treated as a hint; a different size could be used if necessary. A  KEY_BLOCK_SIZE  value specified for an individual index definition overrides the table-level  KEY_BLOCK_SIZE  value. For  InnoDB  tables,  KEY_BLOCK_SIZE  specifies the page size in kilobytes to use for compressed InnoDB  tables. The  KEY_BLOCK_SIZE  value is treated as a hint; a different size could be used by  InnoDB  if necessary.  KEY_BLOCK_SIZE  can only be less than or equal to the innodb_page_size  value. A value of 0 represents the default compressed page size, which is half of the  innodb_page_size  value. Depending on  innodb_page_size , possible  KEY_BLOCK_SIZE values include 0, 1, 2, 4, 8, and 16. See Section 15.9.1, “InnoDB Table Compression”  for more information. Oracle recommends enabling  innodb_strict_mode  when specifying  KEY_BLOCK_SIZE  for  InnoDB tables. When  innodb_strict_mode  is enabled, specifying an invalid  KEY_BLOCK_SIZE  value returns an error. If  innodb_strict_mode  is disabled, an invalid  KEY_BLOCK_SIZE  value results in a warning, and the  KEY_BLOCK_SIZE  option is ignored. The  Create_options  column in response to  SHOW TABLE STATUS  reports the actual KEY_BLOCK_SIZE  used by the table, as does  SHOW CREATE TABLE . InnoDB  only supports  KEY_BLOCK_SIZE  at the table level. KEY_BLOCK_SIZE  is not supported with 32KB and 64KB  innodb_page_size  values.  InnoDB  table compression does not support these pages sizes. InnoDB  does not support the  KEY_BLOCK_SIZE  option when creating temporary tables. The maximum number of rows you plan to store in the table. This is not a hard limit, but rather a hint to the storage engine that the table must be able to store at least this many rows. The use of  MAX_ROWS  with  NDB  tables to control the number of table partitions is deprecated. It remains supported in later versions for backward compatibility, but is subject to removal in a future release. Use PARTITION_BALANCE instead; see Setting NDB_TABLE options. Important The  NDB  storage engine treats this value as a maximum. If you plan to create very large NDB Cluster tables (containing millions of rows), you should use this option to insure that  NDB  allocates sufficient number of index slots in the hash table used for storing hashes of the table’s primary keys by setting MAX_ROWS = 2 *  rows , where  rows  is the number of rows that you expect to insert into the table. The maximum  MAX_ROWS  value is 4294967295; larger values are truncated to this limit. 2557 • INSERT_METHOD • KEY_BLOCK_SIZE • MAX_ROWS