MySQL Bugs: #116780: cluster primary index should mark HA_MRR_INDEX

Bug #116780	cluster primary index should mark HA_MRR_INDEX_ONLY, but it not.
Submitted:	26 Nov 2024 8:43	Modified:	26 Nov 2024 11:34
Reporter:	jump mason	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Server: Optimizer	Severity:	S3 (Non-critical)
Version:	8.0.36	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
the code:
check_quick_select
  if (index_only &&
      (file->index_flags(keynr, seq.max_key_part, true) & HA_KEYREAD_ONLY) &&
      !(pk_is_clustered && keynr == param->table->s->primary_key))
    *mrr_flags |= HA_MRR_INDEX_ONLY;

the primary index for innodb would rejected by !(pk_is_clustered && keynr == param->table->s->primary_key, but it is a index only access.

How to repeat:
no need

Suggested fix:
check_quick_select
  if (index_only &&
      (file->index_flags(keynr, seq.max_key_part, true) & HA_KEYREAD_ONLY) &&
      !(pk_is_clustered && keynr == param->table->s->primary_key))
    *mrr_flags |= HA_MRR_INDEX_ONLY;

==>

check_quick_select
  if ((index_only &&
      (file->index_flags(keynr, seq.max_key_part, true) & HA_KEYREAD_ONLY)) ||
      (pk_is_clustered && keynr == param->table->s->primary_key))
    *mrr_flags |= HA_MRR_INDEX_ONLY;

Hi Mr. mason,

Thank you for your bug report.

However, we do not think that this is a bug.

Since in InnoDB the primary index is always clustered, that means that reading by that index would be almost as expensive as scanning of all rows.

That is why the original code is correct.

Not a bug.