Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Not a Bug
-
10.11.14
-
None
-
AlmaLinux 8.10
-
Unexpected results
Description
EDIT: I forgot to mention that I was using SQL_NO_CACHE (now added) in my first query for performance testing. After removing SQL_NO_CACHE, the correct result count is displayed properly. Both query variants show the same incorrect behavior when SQL_NO_CACHE is added - both display "132321 total" instead of the correct 1313 results. Both show the correct value when SQL_NO_CACHE is removed. The issue here was using "SQL_NO_CACHE".
However, since SQL_NO_CACHE is commonly used for performance testing and causes completely incorrect "total" counts to be displayed, this might still be worth addressing? I'll leave it to the maintainers to decide whether this edge case warrants fixing or if the ticket should be closed.
In my MariaDB 10.11.11 (Windows 11) I see correct values with SQL_NO_CACHE for this queries.
Or is it a bug in PHPMyAdmin?
-------------------------------------------------
When using a query with DISTINCT and multiple JOINs, MariaDB 10.11.14 sometimes returns incorrect results. On the same dataset, MariaDB 10.11.11 or other servers return correct results. This appears to be an optimizer issue, as the problem disappears when replacing JOIN with EXISTS.
The issue is reproducible even with simple tables and does not seem related to the amount of data, but rather to the query structure and version-specific optimizer behavior.
Problematic query using DISTINCT + JOIN:
SELECT SQL_NO_CACHE DISTINCT u.id |
FROM users u |
JOIN votes v1 ON u.id = v1.user_id |
JOIN votes v2 ON u.id = v2.user_id |
WHERE u.last_active > (UNIX_TIMESTAMP(NOW()) - 86400*30) |
AND v1.item_id = 1001 AND v1.vtype = 2 |
AND v2.item_id IN (2001, 2002) AND v2.vtype = 2; |
PhpMyAdmin: "Showing rows 0 - 24 (132321 total, 0 in query, Query took 8.1832 seconds.)"
Observed result: returns all users instead of only those who have voted on both items.
The EXISTS version produces correct results:
SELECT u.id |
FROM users u |
WHERE u.last_active > (UNIX_TIMESTAMP(NOW()) - 86400*30) |
AND EXISTS ( |
SELECT 1 FROM votes v1 |
WHERE v1.user_id = u.id |
AND v1.item_id = 1001 |
AND v1.vtype = 2 |
)
|
AND EXISTS ( |
SELECT 1 FROM votes v2 |
WHERE v2.user_id = u.id |
AND v2.item_id IN (2001, 2002) |
AND v2.vtype = 2 |
);
|
PhpMyAdmin: "Showing rows 0 - 24 (1313 total, Query took 0.0253 seconds.)"
Expected behavior:
MariaDB 10.11.14 should return the same results for the DISTINCT + JOIN query as MariaDB 10.11.11 or when using EXISTS.
Additional notes:
Using ANALYZE TABLE on the involved tables said "OK" and slightly reduces the total count returned by the DISTINCT + JOIN query (by a few hundred rows), but the results remain incorrect overall.
A simple count of active users in the last 30 days returns a reasonable number:
SELECT COUNT(*) FROM users WHERE last_active > (UNIX_TIMESTAMP(NOW()) - 86400*30); |
Result is 6513
However, the DISTINCT + JOIN query returns over 132,321 rows, which is clearly incorrect. This demonstrates that the problem is not due to the dataset size or the last_active filter, but rather a query/optimizer issue.