MySQL raises error 1406 (ER_DATA_TOO_LONG) with SQLSTATE 22001 when a value being inserted or updated is longer than the maximum length declared for a string column. The error message reads: ERROR 1406 (22001): Data too long for column 'column_name' at row N. This error always halts the offending statement and rolls back any row changes from that statement.
What This Error Means
SQLSTATE 22001 is the SQL standard code for a "string data, right truncation" violation. MySQL maps this to the named condition ER_DATA_TOO_LONG. When MySQL encounters a value that would exceed a column's declared length, it refuses to store it rather than silently truncating the data.
The behavior depends on the SQL mode in effect. When STRICT_TRANS_TABLES or STRICT_ALL_TABLES is part of sql_mode (the default since MySQL 5.7.5), MySQL raises a hard error and the statement fails. In non-strict mode (older configurations or explicitly disabled strict mode), MySQL would instead truncate the value silently and emit a warning — a dangerous behavior that can cause data loss.
The error is raised at the storage engine level after the optimizer has already parsed and planned the statement. The row is never written, and the transaction (if one is open) remains active but with that statement's changes rolled back. Other previously committed statements in the same transaction are unaffected.
Common Causes
Application-side input is not validated against the column definition. A form field, API payload, or user-generated string grows beyond what the schema was originally designed to hold — for example, a
VARCHAR(50)column receiving a 200-character username.Schema was defined too narrowly for the actual data. A column was sized for expected data at design time but real-world inputs are longer — e.g., URLs in a
VARCHAR(100), addresses in aVARCHAR(100), or free-text descriptions in aVARCHAR(255).Character set mismatch with multi-byte characters. A
VARCHAR(N)column stores up to N characters, but the byte length depends on the character set. If the column useslatin1but data is inserted via autf8mb4connection, MySQL converts the string; if the converted value is longer than N characters, the error fires. Less common, but also: if a column is declared as a byte-length type and multi-byte input is wider than expected.ORM or framework auto-generates schema with undersized columns. Some ORMs default
stringfields toVARCHAR(191)orVARCHAR(255). When the application allows inputs beyond those limits, the error surfaces at runtime rather than schema creation time.Data migration or ETL pipeline sources longer values than the target schema permits. A column in the source system is wider than the equivalent column in the target MySQL schema.
ENUMvalue not in the allowed list. When an unknown string is assigned to anENUMcolumn in strict mode, MySQL raisesER_DATA_TOO_LONGrather than a more descriptive error — this is a known quirk.
How to Fix ER_DATA_TOO_LONG
Identify the column's current definition and the data causing the overflow.
SELECT COLUMN_NAME, DATA_TYPE, CHARACTER_MAXIMUM_LENGTH, CHARACTER_SET_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_SCHEMA = 'your_database' AND TABLE_NAME = 'your_table' AND COLUMN_NAME = 'your_column';To find the actual length of the value that failed:
SELECT CHAR_LENGTH('the value that caused the error');Increase the column length to accommodate realistic inputs.
ALTER TABLE your_table MODIFY COLUMN your_column VARCHAR(500) NOT NULL;For very long or unbounded text (descriptions, HTML bodies, JSON), prefer
TEXTorMEDIUMTEXTinstead of a widerVARCHAR:ALTER TABLE your_table MODIFY COLUMN description TEXT NOT NULL;Note:
ALTER TABLEon large tables acquires a metadata lock and may require an online DDL strategy. UseALGORITHM=INPLACE, LOCK=NONEwhen supported by your storage engine and MySQL version:ALTER TABLE your_table MODIFY COLUMN your_column VARCHAR(500) NOT NULL, ALGORITHM=INPLACE, LOCK=NONE;Truncate or validate input in the application before sending it to MySQL.
If you cannot or do not want to widen the column, enforce the limit in application code before executing the query. This is often the right fix when the column length is a business rule, not just a technical limit.
Fix ENUM mismatches by inserting only valid values.
If error 1406 is being raised on an
ENUMcolumn, the inserted string is not one of the declared enum values. Either add the new value to theENUMdefinition or correct the application to supply a valid value:ALTER TABLE your_table MODIFY COLUMN status ENUM('active', 'inactive', 'pending', 'archived') NOT NULL;Verify the character set of the column and connection match.
If data originates from a
utf8mb4source but the column is declaredlatin1, some characters may be untranslatable or expand unexpectedly:ALTER TABLE your_table MODIFY COLUMN your_column VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;Check and align sql_mode if migrating from older MySQL.
In pre-5.7 installations without strict mode, the same inserts succeeded via silent truncation. When migrating to MySQL 5.7+ or 8.x, these silent truncations become hard errors. Audit your data and widen columns rather than disabling strict mode:
-- View current sql_mode SELECT @@sql_mode;Disabling strict mode to suppress the error is not recommended — it reintroduces silent data truncation.
Additional Information
- MySQL 5.7.5 enabled
STRICT_TRANS_TABLESin the defaultsql_mode, which is why applications that ran cleanly on 5.6 may start raising 1406 on upgrade. - SQLSTATE
22001("string data, right truncation") is defined in SQL:2003 and is used consistently across MySQL, PostgreSQL, and other databases for this class of length violation. - Related conditions in the same SQLSTATE class 22 include
22003(numeric value out of range) and22007(invalid datetime format). - Most MySQL drivers (Connector/J, mysqlclient, PyMySQL, Go MySQL driver) surface this as a database-level error with the 1406 error code. ORMs like Hibernate, SQLAlchemy, and ActiveRecord will typically wrap it in a driver-specific exception (e.g.,
DataErrorin SQLAlchemy,ActiveRecord::ValueTooLongin Rails 5.1+). - Rails 5.1+ raises
ActiveRecord::ValueTooLongspecifically for this error code, making it straightforward to rescue in application code. CHAR_LENGTH()returns the number of characters;LENGTH()returns bytes. For multi-byte character sets, useCHAR_LENGTH()when comparing against aVARCHAR(N)column limit.
Frequently Asked Questions
Why does MySQL 1406 appear after upgrading from MySQL 5.6 to 5.7 or 8.x, even though nothing else changed?
MySQL 5.7.5 enabled strict SQL mode by default (STRICT_TRANS_TABLES). In MySQL 5.6 with non-strict mode, oversized values were silently truncated and a warning was issued instead of an error. After the upgrade, the same inserts become hard failures. The fix is to widen the affected columns or enforce length validation in the application — not to disable strict mode.
Can I temporarily disable the error to bulk-load legacy data?
You can set sql_mode to a non-strict mode for the duration of a session, but this causes silent truncation — values are cut off without warning in production code. A better approach for bulk loads is to pre-process the source data to truncate or clean oversized values before loading, so you have visibility into what was modified.
-- During a migration session only (not recommended for production application connections)
SET SESSION sql_mode = (SELECT REPLACE(@@sql_mode, 'STRICT_TRANS_TABLES', ''));
Why does MySQL raise error 1406 for an ENUM column when my value is clearly a string?
When strict mode is enabled, inserting a string that is not in an ENUM column's declared list raises ER_DATA_TOO_LONG (1406) rather than a more intuitive "invalid enum value" error. This is a known MySQL quirk. The fix is to either add the new value to the ENUM definition via ALTER TABLE, or correct the application to supply only valid enum members.
Is error 1406 the same as a truncation warning?
No. A truncation warning (which MySQL issues in non-strict mode) means the data was stored in a silently shortened form. Error 1406 means the statement was rejected entirely and no data was written. When you see 1406, your data is safe — it was never stored. Truncation warnings, by contrast, indicate data loss that may already have occurred.