Mysql – Query optimization : abnormal number of row scanned

Here is a table with few millions of data (13701956 rows, 588Mo of data):

CREATE TABLE `countdata_681` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `data` int(11) DEFAULT NULL,
  `date_time` datetime DEFAULT NULL,
  `gmt_offset` smallint(6) NOT NULL DEFAULT '0' COMMENT 'Offset GMT en minute',
  `measurement_id` int(11) NOT NULL,
  `flags` bit(16) NOT NULL DEFAULT b'0' COMMENT 'mot binaire : b1000=validé, b10000000=supprimé',
  PRIMARY KEY (`id`),
  UNIQUE KEY `ak_countdata_idx` (`measurement_id`,`date_time`,`gmt_offset`),
  CONSTRAINT `fk_countdata_measurement_681` FOREIGN KEY (`measurement_id`)
        REFERENCES `eco`.`measurement` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=14352166 DEFAULT CHARSET=utf8 COMMENT='données de comptage'

In this table, I put some traffic information on about 90 different measurement_id and try to identify a max(date_time) and MIN(date_time) for every measurement_id.
So I use the query below :

SELECT D.`measurement_id`,
       MAX(D.date_time) AS maxdate,
       MIN(D.date_time) AS mindate
FROM data_us.countdata_681 D
GROUP BY  D.`measurement_id`

If I use the index ak_countdata_idx, I was thinking that I will need to scan 90 rows for MAX and 90 rows for MIN so about 180rows.
An EXPLAIN of this query give me (scan 28548 rows):

id | select_type | table | type  | possible_keys    | key              | key_len | ref    | rows  | Extra                     
------  -----------  ------  ------  ----------------  ----------------  -------  ------  ------  --------------------------
 1 | SIMPLE      | D     | range | ak_countdata_idx | ak_countdata_idx | 10      | (NULL) | 28548 | Using index for group-by

Why this result? Have you got any suggestion to optimize this query?

EDIT :
Here is the second table I update with this request :
SELECT take 0.05s but UPDATE can take 30s sometimes.

UPDATE eco.`measurement` M
JOIN 
(SELECT D.`measurement_id`,
     MAX(D.date_time) AS maxdate,
     MIN(D.date_time) AS mindate
FROM data_au.countdata_641 D
GROUP BY  D.`measurement_id` ) t
ON M.`id` = t.measurement_id SET M.`last` = t.maxdate,
     M.`begin` = IF(M.`begin` < t.mindate,
     M.`begin`,
     t.mindate)

and the table (120993 rows):

 CREATE TABLE `measurement` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `flow_id` int(11) DEFAULT NULL COMMENT 'null si pas encore rattaché à un site',
  `detector_id` int(11) DEFAULT NULL COMMENT 'rappel: détecteur = externalsystem ou ecosystem ou utilisateur Aladdin',
  `file_id` int(11) DEFAULT NULL COMMENT '!null si importation par fichier',
  `begin` datetime DEFAULT NULL,
  `end` datetime DEFAULT NULL COMMENT 'null si measurement active du detector_id',
  `last` datetime DEFAULT NULL COMMENT 'dernier datetime de countdata (maj visiosync)',
  `domain_id` int(11) NOT NULL COMMENT 'xxxsystem.domain_id pour cette mesure (nécessaire pour éviter le risque de perdre la table countdata)',
  `timezone_id` int(11) NOT NULL COMMENT 'domain.timezone_id ou flow.site.timezone_id pour cette mesure (défini à l''attachement)',
  `timebase` int(11) NOT NULL DEFAULT '0' COMMENT 'périodicité des relevés en seconde (maj visiosync) 0=indéterminé',
  `priority` int(11) NOT NULL DEFAULT '0' COMMENT 'classement des mesures',
  `edited` timestamp NULL DEFAULT CURRENT_TIMESTAMP COMMENT 'date de dernière modification des données (sauf ajout après measurement.last)',
  `lastmodified` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  KEY `fk_measurement_flow_idx` (`flow_id`),
  KEY `fk_measurement_detector_idx` (`detector_id`),
  KEY `fk_measurement_domain_idx` (`domain_id`),
  KEY `fk_measurement_timezone_idx` (`timezone_id`),
  KEY `measurement_begin_idx` (`begin`),
  KEY `measurement_last_idx` (`last`),
  KEY `measurement_end_idx` (`end`),
  CONSTRAINT `fk_measurement_detector` FOREIGN KEY (`detector_id`) REFERENCES `detector` (`id`),
  CONSTRAINT `fk_measurement_domain` FOREIGN KEY (`domain_id`) REFERENCES `domain` (`id`),
  CONSTRAINT `fk_measurement_flow` FOREIGN KEY (`flow_id`) REFERENCES `flow` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION,
  CONSTRAINT `fk_measurement_timezone` FOREIGN KEY (`timezone_id`) REFERENCES `timezone` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3109075 DEFAULT CHARSET=utf8 COMMENT='mesure'

EDIT 2 :

EXPLAIN UPDATE eco.`measurement` M
JOIN 
    (SELECT D.`measurement_id`,
     MAX(D.date_time) AS maxdate,
     MIN(D.date_time) AS mindate
FROM data_us.countdata_681 D
GROUP BY  D.`measurement_id` ) t
ON M.`id` = t.measurement_id 
SET M.`last` = t.maxdate,
     M.`begin` = IF(M.`begin` < t.mindate,
     M.`begin`,
     t.mindate);

    id  select_type  table       type    possible_keys     key               key_len  ref                 rows  Extra                     
------  -----------  ----------  ------  ----------------  ----------------  -------  ----------------  ------  --------------------------
     1  PRIMARY      <derived2>  ALL     (NULL)            (NULL)            (NULL)   (NULL)             28514  (NULL)                    
     1  PRIMARY      M           eq_ref  PRIMARY           PRIMARY           4        t.measurement_id       1  (NULL)                    
     2  DERIVED      D           range   ak_countdata_idx  ak_countdata_idx  10       (NULL)             28514  Using index for group-by 

EDIT 3 :
It seems to be an applicative issue. I open one transaction which create table and alter table to add my index. At a moment, we ALTER TABLE after the data insertion to limit the time of INSERT but finally, with 13M of data, the alter table became very poor performance. If I directly create my table with index, will it solve my issue?
I have after a multi-thread script with a connection pool which populate my countdata table (finally, does this script really populate the index file?).
At the end of my script, I take again my initial transaction and execute my UPDATE which do a full scan.
Can it the stats table from optimizer which are not yet calculate or a tmp table for the alter until commit of my transaction?

Thanks in advance for your help