On version 5.7, repeated results were obtained when using group by
General
Escalation
General
Escalation
Description
Environment
None
Activity
Show:

Aaditya Dubey January 31, 2025 at 12:50 PM
Hi
Thank you for the report.
Please note 5.7 is EOL so we no longer fixes bug on it, please consider upgrading to MySQL 8.0 for correct result sets:
Please consider using English as a language while reporting a bug so that it will be convenient for everyone to understand since this is a public bug DB, and many people look for bugs and their solutions.
Thank you for connecting with Percona.

javvy January 13, 2025 at 9:33 AM
join_init_dead_decord -> join_init_read_record

javvy January 13, 2025 at 9:32 AM
join_init_dead_decord -> join_init_read_decord
Won't Do
Details
Details
Assignee
Unassigned
UnassignedReporter

Needs QA
Yes
Affects versions
Priority
Smart Checklist
Open Smart Checklist
Smart Checklist

Open Smart Checklist
Created January 13, 2025 at 9:18 AM
Updated January 31, 2025 at 12:52 PM
Resolved January 31, 2025 at 12:50 PM
The table creation statement is as follows:
The data in the table is as follows:
The table query statement is as follows:
The query results are as follows:
The execution steps of this query are as follows:
join_init_dead_decord: Sort the data from the privacey_apply table by the field corresponding to group by
rr_unpack_from-buffer, loop to retrieve a record from the sort buffer
evaluate_join_record -> sub_select_op -> QEP_tmp_table:: put_record -> end_write_group, Check if the current record is the same as the previous record. If it is different, it means it is a new group, and start a new count accordingly.
The reason for this bug is that before the first step of sorting is performed, the value of the column corresponding to 'group by' has not been generated yet (generated in step 3) when Sort_param:: make_stortkey generates the sorting key, resulting in invalid sorting and causing a duplicate 'group' to be generated when executing end_write_group in step 3