<p>Raised when a VALUES IN clause supplies a single-field row expression while the partitioning engine expects a multi-field row.</p>
<p>MySQL Error 1658 ER_ROW_SINGLE_PARTITION_FIELD_ERROR occurs when a partition definition uses VALUES IN with only one column, but MySQL expects a multi-column row expression. Use LIST without extra parentheses or provide full row values to fix the issue.</p>
Row expressions in VALUES IN only allowed for multi-field
MySQL raises this error when a partition definition or alteration uses VALUES IN with a row constructor that contains only one field, yet the partitioning expression expects a full multi-column row. The engine cannot map the supplied value to the partition key and aborts the statement.
Developers usually see the error while creating or altering LIST COLUMNS partitions, but it can also appear during import scripts that recreate tables. Understanding why the mismatch happens lets you fix the DDL quickly.
The most common cause is using PARTITION BY LIST COLUMNS(col1) together with VALUES IN ((1),(2)), where each element is wrapped in parentheses and interpreted as a row.
The error is also triggered when the partition key involves multiple columns, yet the VALUES IN clause lists fewer values than columns, creating a length mismatch.
Altering an existing multi-column partitioned table and forgetting to supply all key fields in the new partition definitions will produce the same error.
Confirm how many columns are in the partition key. If the key has one column, remove the extra parentheses and use simple values or switch to LIST instead of LIST COLUMNS.
For multi-column keys, provide full row constructors in the VALUES IN list, matching the same order and data types.
If refactoring is easier, drop and recreate partitions with PARTITION BY RANGE or HASH, which do not rely on VALUES IN.
Single-column LIST mistake: rewrite PARTITION BY LIST(id) ( PARTITION p0 VALUES IN (1,2) ).
Two-column composite key: write PARTITION p1 VALUES IN ((1,'A'),(2,'B')).
During ALTER TABLE ADD PARTITION, replicate the original key order: ALTER TABLE t ADD PARTITION (PARTITION p3 VALUES IN ((3,'C'))).
Always document the partition key explicitly and keep sample DDL in version control.
Use Galaxy to store endorsed DDL snippets so teammates do not re-introduce single-field row expressions.
Add automated review checks that parse CREATE TABLE statements and flag LIST COLUMNS with mismatched VALUES IN lengths.
Error 1493 Partition field count does not match: occurs when the number of partition fields differs from the number of listed values; fix by aligning counts.
Error 1503 A partition function is not allowed: triggered by unsupported expressions in partitioning; rewrite using permitted deterministic expressions.
Supplying VALUES IN ((1),(2)) while partitioning by a single column is the fastest way to hit the error.
Providing fewer values than columns inside the row expression for a multi-column LIST COLUMNS partition leads to the exception.
When adding partitions, developers sometimes copy only the first column of the key, generating the same error.
Raised when the number of partition columns differs from the listed values. Align the counts to resolve.
Occurs when using a non-deterministic or otherwise unsupported function in partition definition. Replace with allowed deterministic expression.
Triggered when attempting unsupported partition operations on an InnoDB table. Check engine capabilities.
Yes, but remove the extra parentheses: VALUES IN (1,2,3). Row constructors like (1) are interpreted as multi-field rows and cause error 1658.
Error 1658 exists in MySQL 5.7 and above. The rules remain the same across versions: row constructor length must equal the partition key length.
You can drop the existing partitions and recreate them with RANGE or HASH partitioning, which do not require VALUES IN clauses.
Galaxy highlights partition syntax in real time and lets teams save corrected DDL snippets, reducing the chance of reintroducing error 1658 in future migrations.