Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 10.0.11
-
Fix Version/s: 10.0.12
-
Component/s: Data Manipulation - Subquery
-
Labels:None
-
Environment:Linux guest 3.2.66-grsec-sma #1 SMP Fri Jan 2 19:09:18 CET 2015 x86_64 GNU/Linux
Description
With the attached dump, under 10.0.11 the following query result 49403 is wrong:
mysql> select version(); +--------------------------+ | version() | +--------------------------+ | 10.0.11-MariaDB-1~wheezy | +--------------------------+ 1 row in set (0.00 sec) mysql> SELECT SQL_CALC_FOUND_ROWS ugyfelid FROM table1 WHERE ugyfelid IN(SELECT ugyfelid FROM table2 WHERE tagid!=2970)ORDER BY osszeg ASC LIMIT 100,1;SELECT FOUND_ROWS(); +----------+ | ugyfelid | +----------+ | 7042 | +----------+ 1 row in set (0.00 sec) +--------------+ | FOUND_ROWS() | +--------------+ | 49403 | +--------------+ 1 row in set (0.00 sec)
The good value under 5.5.41 is 12328:
(root@localhost) [pcszerviz]> select version(); +----------------+ | version() | +----------------+ | 5.5.41-MariaDB | +----------------+ 1 row in set (0.02 sec) (root@localhost) [pcszerviz]> SELECT SQL_CALC_FOUND_ROWS ugyfelid FROM table1 WHERE ugyfelid IN(SELECT ugyfelid FROM table2 WHERE tagid!=2970)ORDER BY osszeg ASC LIMIT 100,1;SELECT FOUND_ROWS(); +----------+ | ugyfelid | +----------+ | 7042 | +----------+ 1 row in set (0.30 sec) +--------------+ | FOUND_ROWS() | +--------------+ | 12328 | +--------------+ 1 row in set (0.00 sec)
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
We had several iterations of fixing issues related to FOUND_ROWS().
Your particular flavor was fixed in 10.0.12 by the following revision:
It works okay on the current tree, too: