Why is a slow query obtained when using PRIMARY KEY in SELECT?

Question

MySQL

I've been fighting for a day now, I can't understand why if you use the primary key in the selection, the selection is slower.
Table structure

CREATE TABLE notifications (
  _id INT(11) NOT NULL AUTO_INCREMENT,
  status INT(11) DEFAULT NULL,
  sender VARCHAR(255) DEFAULT NULL,
  receiver VARCHAR(255) DEFAULT NULL,
  subject VARCHAR(512) DEFAULT NULL,
  message TEXT DEFAULT NULL,
  PRIMARY KEY (_id)
)
ENGINE = INNODB
AUTO_INCREMENT = 5
CHARACTER SET utf8
COLLATE utf8_general_ci;

INSERT INTO notifications VALUES
(1, 3, '[email protected]', '[email protected]', 'Subj', '123'),
(2, 3, '[email protected]', '[email protected]', 'Subj', '123'),
(3, 3, '[email protected]', '[email protected]', 'Subj', '123'),
(4, 3, '[email protected]', '[email protected]', 'Subj', '123');

Queries on a remote machine, Windows Server 2008 (64 bit), MySQL 5.5.8-log

SELECT subject,_id FROM `notifications` WHERE `status` = 1; -- 0,041c [0,013c выполнение, 0,028c выборка]
SELECT subject FROM `notifications` WHERE `status` = 1; -- 0,014c [0,013c выполнение, 0,001c выборка]

Requests on a remote machine in LAN, Windows 7 (64 bit), MySQL 5.5.25, SSD

SELECT subject,_id FROM `notifications` WHERE `status` = 1; -- 0,005c [0,001c выполнение, 0,004c выборка]
SELECT subject FROM `notifications` WHERE `status` = 1; -- 0,002c [0,001c выполнение, 0,001c выборка]

Queries on local machine, Windows 7 (64 bit), MySQL 5.6.15-log

SELECT subject,_id FROM `notifications` WHERE `status` = 1; -- 0,004c [< 0,001c выполнение, 0,004c выборка]
SELECT subject FROM `notifications` WHERE `status` = 1; -- 0,001c [< 0,001c выполнение, 0,001c выборка]

Queries on local machine, Ubuntu, MySQL 5.6

SELECT subject,_id FROM `notifications` WHERE `status` = 1; -- 0,0001c
SELECT subject FROM `notifications` WHERE `status` = 1; -- 0,0001c

If you add any fields to the select, except for _id, then the selection is fast, but if you add a primary key, the selection becomes slower.
This problem is not observed in Ubuntu If anyone else has linux, please check.
What could be the problem?
For more difference I tried to make more records

DELIMITER $$
CREATE PROCEDURE insert_test_data()
BEGIN
  DECLARE i INT DEFAULT 1;

  WHILE i < 10000 DO
    INSERT INTO `notifications` (`status`, `sender`, `receiver`, `subject`, `message`)
    SELECT `status`, `sender`, `receiver`, `subject`, `message`
    FROM `notifications`
    WHERE _id = 1;
    SET i = i + 1;
  END WHILE;
END$$
DELIMITER ;
CALL insert_test_data();
DROP PROCEDURE insert_test_data;

At 10000 entries, the execution time hasn't changed.
If anyone has Windows 32 bit, please check with yourself, because. I dont have an opportunity (

Answer 1

I have mysql Ver 14.14 Distrib 5.5.35, for debian-linux-gnu (x86_64) using readline 6.2
both queries run the same - 0.0001 sec.
Have you tried changing the order of the fields?

SELECT <b>_id</b>, subject FROM `notifications` WHERE `status` = 1;

Purely theoretically, it should not affect, but maybe it affects the Windows platform somehow?
Also wondering if your result will change if you add a key to `status`:
KEY `status` (`status`)

Answer 2

Perhaps the request is cached and the second time the result is taken from the cache, and the entire request is not executed.