¿Por qué MySQL necesita agregar el número 2 al calcular scan_time para la función de escaneo de tablas?

Al calcular scan_time para el escaneo de la tabla, ¿por qué MySQL necesita agregar el número 2 en la siguiente línea? ¿Cuál es la razón o el propósito de agregar 2? URL del código

return(ulonglong2double(stats.data_file_length) / IO_SIZE + 2 );

ha_innobase::scan_time()
/*====================*/
{
    /* Since MySQL seems to favor table scans too much over index
    searches, we pretend that a sequential read takes the same time
    as a random disk read, that is, we do not divide the following
    by 10, which would be physically realistic. */

    /* The locking below is disabled for performance reasons. Without
    it we could end up returning uninitialized value to the caller,
    which in the worst case could make some query plan go bogus or
    issue a Valgrind warning. */

    if (m_prebuilt == NULL) {
        /* In case of derived table, Optimizer will try to fetch stat
        for table even before table is create or open. In such
        cases return default value of 1.
        TODO: This will be further improved to return some approximate
        estimate but that would also needs pre-population of stats
        structure. As of now approach is in sync with MyISAM. */
        return(ulonglong2double(stats.data_file_length) / IO_SIZE + 2);
    }

    ulint   stat_clustered_index_size;

    ut_a(m_prebuilt->table->stat_initialized);

    stat_clustered_index_size =
        m_prebuilt->table->stat_clustered_index_size;

    return((double) stat_clustered_index_size);
}
Answer

Una adivinanza...

+1 podría estar justificado para el siguiente ejemplo: un escaneo que comienza en el medio de un bloque y termina en el medio del siguiente bloque necesita recuperar 2 bloques, mientras toca solo el valor de filas de 1 bloque.

El otro +1 lo atribuiría a los gastos generales generales (ubicar y abrir la mesa).