DYNAMIC Row Format •Records in the clustered index contain fields for all user-defined columns. In addition, there is a 6-byte transaction ID field and a 7-byte roll pointer field. •If no primary key is defined for a table, each clustered index record also contains a 6-byte row ID field. •Each secondary index record contains all the primary key columns defined for the clustered index key that are not in the secondary index. If any of the primary key columns are variable length, the record header for each secondary index has a variable-length part to record their lengths, even if the secondary index is defined on fixed-length columns. •Internally, for nonvariable-length character sets, fixed-length character columns such as  CHAR(10)  are stored in a fixed-length format. •Internally, for variable-length character sets such as  utf8mb3  and  utf8mb4 ,  InnoDB  attempts to store CHAR( N )  in  N  bytes by trimming trailing spaces. If the byte length of a  CHAR( N )  column value exceeds  N bytes, trailing spaces are trimmed to a minimum of the column value byte length. The maximum length of a  CHAR( N )  column is the maximum character byte length ×  N . Trailing spaces are not truncated from  VARCHAR  columns. A minimum of  N  bytes is reserved for  CHAR( N ) . Reserving the minimum space  N  in many cases enables column updates to be done in place without causing index page fragmentation. By comparison, CHAR( N )  columns occupy the maximum character byte length ×  N  when using the  REDUNDANT  row format. Fixed-length columns greater than or equal to 768 bytes are encoded as variable-length fields, which can be stored off-page. For example, a  CHAR(255)  column can exceed 768 bytes if the maximum byte length of the character set is greater than 3, as it is with  utf8mb4 . The  DYNAMIC  row format offers the same storage characteristics as the  COMPACT  row format but adds enhanced storage capabilities for long variable-length columns and supports large index key prefixes. When a table is created with  ROW_FORMAT=DYNAMIC ,  InnoDB  can store long variable-length column values (for  VARCHAR ,  VARBINARY , and  BLOB  and  TEXT  types) fully off-page, with the clustered index record containing only a 20-byte pointer to the overflow page. Fixed-length fields greater than or equal to 768 bytes are encoded as variable-length fields. For example, a  CHAR(255)  column can exceed 768 bytes if the maximum byte length of the character set is greater than 3, as it is with  utf8mb4 . Whether columns are stored off-page depends on the page size and the total size of the row. When a row is too long, the longest columns are chosen for off-page storage until the clustered index record fits on the B-tree page.  TEXT  and  BLOB  columns that are less than or equal to 40 bytes are stored in line. The  DYNAMIC  row format maintains the efficiency of storing the entire row in the index node if it fits (as do the  COMPACT  and  REDUNDANT  formats), but the  DYNAMIC  row format avoids the problem of filling B-tree nodes with a large number of data bytes of long columns. The  DYNAMIC  row format is based on the idea that if a portion of a long data value is stored off-page, it is usually most efficient to store the entire value off-page. With  DYNAMIC  format, shorter columns are likely to remain in the B-tree node, minimizing the number of overflow pages required for a given row. The  DYNAMIC  row format supports index key prefixes up to 3072 bytes. Tables that use the  DYNAMIC  row format can be stored in the system tablespace, file-per-table tablespaces, and general tablespaces. To store  DYNAMIC  tables in the system tablespace, either disable innodb_file_per_table  and use a regular  CREATE TABLE  or  ALTER TABLE  statement, or use 3168 DYNAMIC Row Format