PolarDB for MySQL does not apply parallel query to all query patterns, and parallel execution can produce results that differ from serial execution in predictable ways. This topic covers both categories so you can quickly determine whether your query is affected and how to respond.
Limits on parallel queries
Parallel query does not apply to the following:
Queries on non-InnoDB tables.
Queries that use full-text indexes.
Stored procedures, which are always executed by the leader.
Queries that scan tables using INDEX-MERGE joins.
Queries inside serializable transactions.
INSERT ... SELECTandREPLACE ... SELECTstatements inside transactions when the isolation level is Repeatable Read.
Inconsistencies between parallel and serial execution
Parallel execution introduces intermediate results that do not exist in serial execution. This can cause the following behavioral differences.
More error messages than serial execution
If a query produces errors under serial execution, the same query under parallel execution may return more error messages. Each worker independently encounters and reports errors, so the total count can be higher.
No action is required. This is expected behavior in parallel execution.
Floating-point precision differences
Serial execution does not store intermediate results. Parallel execution stores intermediate results, and if those results are floating-point numbers, precision may differ from the serial execution path. This can cause small numeric differences in the final output.
No action is required. This is expected behavior when intermediate floating-point results are aggregated across workers.
max_allowed_packet limit exceeded
Serial execution does not produce intermediate results. Parallel execution does, and if an intermediate result exceeds the size limit set by max_allowed_packet, an error may be returned.
To resolve this, increase the value of max_allowed_packet. For instructions, see Specify cluster and node parameters.
Result set order may differ
SELECT ... LIMIT n without ORDER BY may return rows in a different order under parallel execution. Multiple workers run simultaneously, and after the leader collects enough rows, the results are returned. Because worker execution speed varies across runs, the row order is non-deterministic.
More rows acquire row locks
SELECT ... FROM ... FOR SHARE under parallel execution causes InnoDB to lock each row accessed by all workers. The number of rows with row locks may exceed what non-parallel execution would lock.
No action is required. This is expected behavior in parallel execution.