We see that MySQL needs to add the ranges when calculate the ha_innobase::read_time (/storage/innobase/handler/ha_innobase.cc), my question is why it need it?

double ha_innobase::read_time(
    uint    index,  /*!< in: key number */
    uint    ranges, /*!< in: how many ranges */
    ha_rows rows)   /*!< in: estimated number of rows in the ranges */
{
    ha_rows total_rows;

    if (index != table->s->primary_key) {
        /* Not clustered */
        return(handler::read_time(index, ranges, rows));
    }

    if (rows <= 2) {

        return((double) rows);
    }

    /* Assume that the read time is proportional to the scan time for all
    rows   at most one seek per range. */

    double  time_for_scan = scan_time();

    if ((total_rows = estimate_rows_upper_bound()) < rows) {

        return(time_for_scan);
    }

    return(ranges   (double) rows / (double) total_rows * time_for_scan);
}

CodePudding user response：

This comment tells you the answer:

/* Assume that the read time is proportional to the scan time for all
rows   at most one seek per range. */

There is probably a seek for each range, and each seek increases the read time. Seeks were more costly on spinning storage devices, and most sites now use solid-state storage, but seeks are still a little bit costly. So it's important to count them when calculating the total read time.