<p>MySQL throws error 1390 (ER_PS_MANY_PARAM) when a prepared statement has more than 65,535 parameter markers.</p>
<p>MySQL Error 1390 ER_PS_MANY_PARAM appears when a prepared statement exceeds the 65,535-parameter limit. Reduce the number of placeholders or split the query to fix the issue.</p>
Prepared statement contains too many placeholders
Error 1390 fires when MySQL parses a prepared statement containing more than 65,535 placeholders (?). The parser tracks each marker and aborts once the hard limit is breached.
The error surfaces immediately after the PREPARE statement is issued, stopping execution before any data manipulation occurs. Applications relying on large IN lists or bulk insert helpers hit this ceiling most often.
MySQL allocates one byte per parameter index inside the prepared statement metadata. Because one byte can map only 65,535 distinct positions, the server sets that as a safety bound to prevent memory misuse.
Cross-version tests confirm this limit in MySQL 5.7, 8.0, and 8.1. None of the current forks raise the ceiling, so architectural changes, not configuration tweaks, are needed.
Excessive dynamic IN lists generated by ORMs often exceed the limit when selecting thousands of IDs at once. Bulk INSERT helpers that bind every column value through placeholders also push counts upward.
ETL jobs merging wide tables with hundreds of columns across tens of thousands of rows can inadvertently cross the threshold while batching data for speed.
Count the markers before sending the query. When above 65,535, split the workload into multiple smaller statements or load the data with LOAD DATA INFILE.
For large IN filters, insert the IDs into a temporary table and join instead of listing them as parameters. Galaxy users can let the editor highlight placeholder counts and refactor queries with one click.
Bulk INSERT of a 300-column table for 300 rows creates 90,000 parameters. Break it into two batches of 150 rows to stay within limits.
Selecting by 80,000 IDs in an IN clause generates 80,000 placeholders. Move the IDs into a temp table and join on that table for faster and safer execution.
Monitor parameter counts in development. Set assertions in your data layer that refuse to prepare statements once the marker total passes 60,000.
Prefer set-based operations such as INSERT ... SELECT and LOAD DATA INFILE. These approaches bind fewer parameters and scale better.
Error 1210 (ER_ERRNO_TOO_MANY_HANDLES) arises when sessions exceed file handle limits. Adjust system ulimits. Error 1114 (ER_RECORD_FILE_FULL) happens when temporary tables run out of space; expand tmpdir or use MEMORY engine cautiously.
ORMs that serialize huge collections into IN (?) placeholders quickly exceed the parameter ceiling.
Batch-loading wide tables multiplies placeholders by row count, breaching 65,535 markers.
Ad-hoc tools may auto-generate queries with thousands of bind parameters to avoid string concatenation.
Occurs when MySQL exhausts file descriptors - raise ulimit or adjust open_files_limit.
Triggered when a temporary table cannot grow - expand tmpdir or convert to InnoDB.
Raised when parameter count exceeds limit in semi-sync replication context - fix similarly by reducing placeholders.
No. The limit is hard-coded in MySQL source.
No. All current GA versions retain the same cap.
Named parameters still compile to anonymous markers internally, so the total count remains the same.
Galaxy counts placeholders in real-time, flags queries that exceed safe thresholds, and suggests splitting or rewriting automatically.
.avif)
.avif){kind=logo}
