content_image/709673.jpg content_image/709679.jpg
## InnoDB Table Compression 

The “non-strict”  behavior lets you import a mysqldump  file into a database that does not support compressed tables, even if the source database contained compressed tables. In that case, MySQL creates the table in ROW_FORMAT=DYNAMIC  instead of preventing the operation. 

To import the dump file into a new database, and have the tables re-created as they exist in the original database, ensure the server has the proper setting for the innodb_file_per_table  configuration parameter. 

The attribute KEY_BLOCK_SIZE  is permitted only when ROW_FORMAT  is specified as COMPRESSED  or is omitted. Specifying a KEY_BLOCK_SIZE  with any other ROW_FORMAT  generates a warning that you can view with SHOW WARNINGS . However, the table is non-compressed; the specified KEY_BLOCK_SIZE  is ignored). 

<img src='content_image/709673.jpg'>

If you are running with innodb_strict_mode  enabled, the combination of a KEY_BLOCK_SIZE  with any ROW_FORMAT  other than COMPRESSED  generates an error, not a warning, and the table is not created. 

Table 15.12, “ROW_FORMAT and KEY_BLOCK_SIZE Options”  provides an overview the ROW_FORMAT and KEY_BLOCK_SIZE  options that are used with CREATE TABLE  or ALTER TABLE . 

<img src='content_image/709679.jpg'>

Table 15.13, “CREATE/ALTER TABLE Warnings and Errors when InnoDB Strict Mode is OFF” summarizes error conditions that occur with certain combinations of configuration parameters and options 

