Skip to content
IntoSQL home
Convert a file

Data types

MySQL data types between versions

Every MySQL data type an older or newer MySQL stores differently, what the converter writes for it, and the report line.

View as Markdown

Each row is a type from MySQL that an older or newer MySQL stores differently: what the script gets, why, and the line the report writes about it. The rows come from the converter's own rules, so this page matches what it does.

Convert in the browser: MySQL to MySQL opens the converter set up for this pair. The MySQL to MySQL migration guide covers dumping, loading and the rules for keys, indexes and names.

A report line is a fix when the converter changed something and lists it, or a problem when a value or object is worth a look.

Numbers

In the dump In the script Why Report line
UNSIGNED and ZEROFILL kept The same types. None

Booleans and bits

In the dump In the script Why Report line
TINYINT(1), BOOL TINYINT(1) The same type with the same values. None

Text

In the dump In the script Why Report line
NUL bytes in text kept The value is copied with the same escape the source used. None
text that isn't valid in its character set the bad bytes as the replacement character The script is UTF-8; bytes that aren't would stop the load. invalid_utf8_replaced (problem)

Enums and sets

In the dump In the script Why Report line
ENUM and SET, the '' error value included kept The same types; the script loads without strict mode, so the error value loads as it is. None

Dates and times

In the dump In the script Why Report line
zero, partial or impossible dates (0000-00-00, 2024-02-30) kept The script loads with ALLOW_INVALID_DATES and without NO_ZERO_DATE, so MySQL keeps the same values the source had. None
TIME TIME, durations included The same type, with the same range. None
TIMESTAMP kept, loaded in the time zone the dump states The script sets the same time zone the dump did, so every moment is the same. None

Binary

In the dump In the script Why Report line
BINARY, VARBINARY, BLOB kept Bytes stay bytes. None

JSON, spatial and other types

In the dump In the script Why Report line
JSON JSON MySQL reads the same JSON text. None
GEOMETRY, POINT, POLYGON... kept, with each value's SRID The server's own geometry bytes are copied, SRID included. None
INET4, INET6, UUID (MariaDB) varchar(15), varchar(39), char(36) MySQL has no such types; the text MariaDB writes for them is kept. type_replaced (fix)
geometries in a dump without CREATE TABLE GEOMETRY MySQL's geometry format is recognised from the values. None
types IntoSQL doesn't know LONGBLOB A blob holds any value's bytes; change the type after loading. unknown_type (problem)
values that don't fit their column NULL A damaged or hand-written dump can hold values its column can't; they become NULL so the rest loads. invalid_value_null (problem)
unreadable geometries NULL Bytes that aren't a geometry can't be stored as one. bad_geometry (problem)
VECTOR(n) (MariaDB 11.7+) json with the floats as an array MySQL 5.7 and 8.0 have no vector type; a JSON array keeps every float on every version. type_replaced (fix)

Counters and identities

In the dump In the script Why Report line
AUTO_INCREMENT AUTO_INCREMENT with the table's counter The counter continues where the source left it, MyISAM's per-group counters included. None
MyISAM AUTO_INCREMENT on the second column of a key, in a table that isn't MyISAM in the dump an index on the column and one counter for the table InnoDB counts a column only when it leads an index, and once for the whole table. myisam_group_autoincrement (problem)

Other pairs