(opens in a new tab)

MySQL Error 1059: Identifier Name Is Too Long

October 25, 2026 by Chat2DB Team

A migration fails on a table, index or constraint name:

ERROR 1059 (42000): Identifier name 'customer_subscription_billing_history_with_tax_adjustments_by_region' is too long

MySQL limits most object names to 64 characters and, unlike PostgreSQL, it refuses longer names instead of silently truncating them. That is the safer behaviour, but it surprises people in three situations: when the name MySQL generates for a foreign key or check constraint goes over the limit even though your own names are shorter, when a schema is ported from another database with longer limits, and with non-ASCII table names.

This guide covers each case with output from MySQL 8.4, lists the limits for every object type, and shows how to fix the error in plain SQL and in common ORMs.

The 64-Character Limit

Databases, tables, columns, indexes, constraints, views, stored routines, triggers, events and partitions all share the same limit of 64 characters:

CREATE TABLE customer_subscription_billing_history_with_tax_adjustments_by_region (id INT);
-- ERROR 1059 (42000): Identifier name '...' is too long      (69 characters)
 
CREATE TABLE customer_subscription_billing_history_with_tax_adjustments_by_r (id INT);
-- Query OK                                                    (63 characters)

It applies to every kind of name you choose:

CREATE TABLE t (id INT, the_total_amount_of_money_received_from_customers_during_the_year INT);
-- ERROR 1059 (42000): Identifier name 'the_total_amount_of_money_received_from_customers_during_the_year' is too long
 
ALTER TABLE t ADD INDEX idx_t_a_with_a_really_long_descriptive_name_for_reporting_queries_2026 (a);
-- ERROR 1059 (42000): Identifier name 'idx_t_a_with_a_really_long_descriptive_name_for_reporting_queries_2026' is too long
 
CREATE DATABASE analytics_warehouse_for_the_customer_success_team_quarterly_reports_v2;
-- ERROR 1059 (42000): Identifier name 'analytics_warehouse_for_the_customer_success_team_quarterly_reports_v2' is too long

Stored procedures, functions and partition names fail the same way. The limit counts characters, not bytes, and it applies after removing backticks, so quoting a name does not help.

The Hidden Case: Generated Constraint Names

When you declare a foreign key or check constraint without a name, MySQL generates one from the table name: <table>_ibfk_<n> for InnoDB foreign keys and <table>_chk_<n> for check constraints. Those generated names must also fit in 64 characters, so a table whose own name is legal can still fail:

CREATE TABLE order_line_items_with_extended_warehouse_fulfillment_details_v2 (
  id INT PRIMARY KEY,
  parent_id INT,
  FOREIGN KEY (parent_id) REFERENCES t(id)
);
-- ERROR 1059 (42000): Identifier name 'order_line_items_with_extended_warehouse_fulfillment_details_v2_ibfk_1' is too long

The table name is 63 characters, which is fine. The generated _ibfk_1 suffix pushes the constraint name to 70. Check constraints behave the same:

CREATE TABLE ck_with_a_very_long_table_name_for_checking_the_generated_name_x (a INT, CHECK (a > 0));
-- ERROR 1059 (42000): Identifier name 'ck_with_a_very_long_table_name_for_checking_the_generated_name_x_chk_1' is too long

The error message names the generated constraint, which makes it easy to misread as a problem with your table name. The fix is to give the constraint an explicit, shorter name:

CREATE TABLE order_line_items_with_extended_warehouse_fulfillment_details_v2 (
  id INT PRIMARY KEY,
  parent_id INT,
  CONSTRAINT fk_olix_parent FOREIGN KEY (parent_id) REFERENCES t(id)
);

The same problem can appear later. Renaming a table to a longer name, or ALTER TABLE ... ADD FOREIGN KEY without a name on a long table, generates _ibfk_2, _ibfk_3 and so on, each needing room for the suffix. As a rule, keep table names under 57 characters if you rely on generated constraint names, or always name constraints yourself.

Other Name Limits in MySQL

Not every name follows the 64-character rule, and some violations produce different error codes:

The view case catches people out because the same SELECT works on its own:

SELECT 1 AS this_is_a_very_long_column_alias_that_definitely_exceeds_the_sixty_four_character_limit_by_a_lot;
-- works: the alias is 96 characters
 
CREATE VIEW v AS
SELECT 1 AS this_is_a_very_long_column_alias_that_definitely_exceeds_the_sixty_four_character_limit_by_a_lot;
-- ERROR 1166 (42000): Incorrect column name 'this_is_a_very_long_column_alias_that_definitely_exceeds_the_sixty_four_character_limit_by_a_lot'

View columns become real column names in the data dictionary, so they must follow the 64-character rule. Give long expressions a shorter alias, or list the view's column names explicitly: CREATE VIEW v (short_name) AS SELECT ....

User names longer than 32 characters fail with a different message:

CREATE USER 'a_really_long_user_name_for_the_reporting_service_2026'@'%' IDENTIFIED BY '...';
-- ERROR 1470 (HY000): String 'a_really_long_user_name_for_the_reporting_service_2026' is too long for user name (should be no longer than 32)

Non-ASCII Table Names Hit a Lower Limit

The 64-character limit counts characters, so a name in Chinese, Japanese or Cyrillic is allowed up to 64 characters in principle. But InnoDB stores each table in a file named after the table, and characters outside a safe ASCII set are encoded in the file name as @xxxx (five bytes per character). The file name, plus .ibd, must fit within the operating system's 255-byte limit.

In our test on Linux, 50 CJK characters worked and 51 failed, with a confusing storage engine error instead of 1059:

CREATE TABLE `表表表...表` (id INT);   -- 50 characters: OK
CREATE TABLE `表表表...表表` (id INT); -- 51 characters:
-- ERROR 1030 (HY000): Got error 168 - 'Unknown (generic) error from engine' from storage engine

A 65-character CJK name fails earlier with ERROR 1103 (42000): Incorrect table name. If you use non-ASCII table names, keep them short, or use ASCII names and put the human-readable name in the table COMMENT.

Porting Schemas From Other Databases

Limits differ between engines, so a schema that is valid elsewhere can fail on MySQL:

Migrations from SQL Server and Oracle are the usual source of 1059 errors, because names of 65 to 128 characters are legal there. Before converting, list the long names in the source database and decide on short replacements. A name-mapping table in your migration scripts keeps the renames consistent across tables, indexes and application code.

Going the other way, a MySQL schema always fits within PostgreSQL's 63-byte limit only if the names are ASCII and at most 63 characters. The Postgres Identifier Checker (opens in a new tab) shows how each name would be stored there.

Fixing It in ORMs and Migration Tools

Most frameworks build index and foreign key names from table and column names, which can exceed 64 characters:

• Laravel generates names like table_column_foreign and table_column_index. Pass a name as the second argument: $table->foreign('parent_id', 'fk_olix_parent') or $table->index(['a', 'b'], 'idx_ab').
• Rails generates index_<table>_on_<columns> and checks the length itself. Use add_index :table, [:a, :b], name: "idx_ab".
• Django truncates generated index and constraint names to fit the backend's limit and adds a hash, so it rarely produces 1059. Explicit db_table or name= values must still be 64 characters or less.
• Hibernate/JPA generates hashed names like FK8xhq... that are short. Explicit @Table(name=...), @Index(name=...) and @ForeignKey(name=...) values must respect the limit.
• Prisma, TypeORM, Sequelize: set map: or explicit constraint names on long relations.

Choosing Short, Stable Names

A naming convention prevents most 1059 errors before they happen. A few rules that work well in practice:

• Give tables plural nouns of one to three words (orders, order_items, billing_events), not sentences.
• Use common abbreviations consistently (qty, amt, addr, acct) and document them.
• Name constraints and indexes yourself with short prefixes: pk_, fk_<child>_<parent>, uq_, idx_, chk_.
• Keep version suffixes like _v2 and _new out of permanent names. Rename the table when the migration is finished instead.

Finding Names Close to the Limit

Before a rename or a migration, find existing names that are already long:

SELECT TABLE_NAME, CHAR_LENGTH(TABLE_NAME) AS len
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = DATABASE() AND CHAR_LENGTH(TABLE_NAME) > 55
ORDER BY len DESC;
 
SELECT TABLE_NAME, CONSTRAINT_NAME, CHAR_LENGTH(CONSTRAINT_NAME) AS len
FROM information_schema.TABLE_CONSTRAINTS
WHERE CONSTRAINT_SCHEMA = DATABASE() AND CHAR_LENGTH(CONSTRAINT_NAME) > 55;

Tables near 57 characters are the ones that will fail the next time someone adds an unnamed foreign key or check constraint.

When you work through a long list of renames, a GUI saves time. Chat2DB (opens in a new tab) shows the full DDL of each table, including generated constraint names, and its AI assistant can propose consistent short names and generate the RENAME TABLE and ALTER TABLE ... RENAME INDEX statements.

FAQ

Can I increase the 64-character limit in MySQL?

No. NAME_LEN (64) is compiled into the server and also used by the data dictionary. There is no configuration variable for it. The only fix is a shorter name.

Why does MySQL complain about a name I never wrote?

The name was generated. Unnamed foreign keys get <table>_ibfk_<n> and unnamed check constraints <table>_chk_<n>. With a table name longer than about 57 characters, the generated name goes over 64. Name the constraint explicitly.

Does MySQL truncate long identifiers like PostgreSQL does?

No. MySQL rejects the statement with error 1059 and creates nothing. PostgreSQL silently cuts names to 63 bytes and only prints a notice, which can lead to two different names becoming the same object.