Details
-
Bug
-
Status: Confirmed (View Workflow)
-
Critical
-
Resolution: Unresolved
-
11.4.7, 11.8.2
-
docker and CloudLinux 8
Description
The query
PREPARE stmt FROM 'SELECT 5 AS Y, 6 AS M |
FROM orders AS o
|
INNER JOIN (
|
SELECT orderID
|
FROM orderItems
|
GROUP BY orderID
|
) AS oi ON oi.orderID = o.id
|
INNER JOIN addresses AS a ON a.id = o.shippingAddressID
|
WHERE o.isInStats = 1 AND a.countryID = ? AND YEAR(o.orderTime) = ?
|
ORDER BY 1 DESC, 2 DESC;'; |
EXECUTE stmt USING '1','2025'; |
EXECUTE stmt USING '50','2025'; |
EXECUTE stmt USING '65','2025'; |
EXECUTE stmt USING '151','2025'; |
is stuck in a loop sorting keys. This is a regression from 10.6 to 11.4.
There is a chat thread here about it: https://mariadb.zulipchat.com/#narrow/channel/118759-general/topic/Debug.20long.20running.20query/with/523721319
I am not yet able to produce a data set that I can attach here, but the current sql-file is 306M and if I decrease the number of inserts with around 1000 inserts, the query starts to behave.
Workarounds:
1) SET optimizer_switch='extended_keys=off' No longer works, I assume that dataset grew a bit.
2)
SET SESSION tmp_memory_table_size = 16384; SET SESSION max_heap_table_size = 16384;
|
3)
SET SESSION max_heap_table_size = 19198290;
|
Our default value of max_heap_table_size is 256M, it seems that going from the default 16M to 32M breaks the query.
Both work separately. 1) does not work when I replicate via docker, only on CloudLinux.
Changes that manage to make the query not ending up in a loop:
1) If I run the queries without prepare, they work.
2) They have to be in that order, if not, it just works.
3) By removing the
GROUP BY orderID
|
it works.
Attachments
Issue Links
- relates to
-
MDEV-36940 Execution plan for prepared statement loses optimization after some executions
-
- Needs Feedback
-