Как тип блочного устройства влияет на скрость mysql?

Может диск пора менять? Возьми викторию и пусть посмотрит состояние диска.

Может просто из-за старости диска тормозить. Например части некоторых строк приходятся на отремапеные сектора и диску приходится лишний раз елозить головками. При чём при повторном запросе этой строки (в течении какого-то времени) ответ будет возвращаться быстро (ибо дисковый кеш и кеш запросов).
Строки в таблице большие? Какие типы колонок?

Так про диск и подумал. SMART говорит, что ему конец.

receipts | CREATE TABLE `receipts` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `created_at` datetime DEFAULT NULL,
  `updated_at` datetime DEFAULT NULL,
  `cashbox_shift_id` int(11) NOT NULL,
  `sum` decimal(10,2) DEFAULT NULL,
  `sum_with_discount` decimal(10,2) DEFAULT NULL,
  `cashbox_operation_id` int(11) DEFAULT NULL,
  `discount` decimal(10,2) DEFAULT '0.00',
  `discount_barcode` varchar(255) DEFAULT NULL,
  `sum_of_vat10` decimal(10,2) DEFAULT NULL,
  `sum_of_vat10_with_discount` decimal(10,2) DEFAULT NULL,
  `sum_of_vat18` decimal(10,2) DEFAULT NULL,
  `sum_of_vat18_with_discount` decimal(10,2) DEFAULT NULL,
  `payment_method` varchar(255) NOT NULL,
  `is_blocked` tinyint(1) DEFAULT '0',
  `kpk_number` int(11) DEFAULT NULL,
  `promotion_barcode` varchar(255) DEFAULT NULL,
  `prescription_barcode` varchar(255) DEFAULT NULL,
  `is_paid` tinyint(1) DEFAULT '0',
  `lottery_number` varchar(255) DEFAULT NULL,
  `uuid` varchar(36) DEFAULT NULL,
  `closed_at` datetime DEFAULT NULL,
  `processed_at_with_ms` decimal(17,3) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `index_receipts_on_uuid` (`uuid`),
  KEY `index_receipts_on_cashbox_shift_id` (`cashbox_shift_id`)
) ENGINE=InnoDB AUTO_INCREMENT=146265 DEFAULT CHARSET=utf8

Если эксплейн говорит всегда 0.4 мс, может 500 мс из-за лока какого-нибудь происходит? %)

Хотел уже, не приходя в сознание, объяснить что explain просто предсказывает вероятное время выполнения запроса, но вдруг осознал что он вообще ничего не говорит о времени выполнения запроса.

Время которое выдаёт explain под табличкой это время выполнения самого explain, т.е. время построение плана выполнения запроса. Со временем выполнения запроса оно коррелирует, но не всегда и очень слабо.

Стоит задуматься о замене диска. Во всяком случае если данные жалко потерять или если эти периодические задержки критичны.
Возможно будет профит даже от замены диска на флешку (линейное чтение медленнее, но рандомный доступ быстрее (не надо елодить головками по блинам), для РСУБД это хорошо).

0,4 это когда индекс в кеше (= в памяти). 500 мс это когда индекс вытеснен из кеша (= считывание с диска). так как диск старый умирающий, то _возможно_ диск работает в PIO режиме и, соответственно, считывание очень медленное.

Реквестирую впереть mysqltuner и посмотреть, хватает ли индексам веделенной оперативы в конфиге. Телепатирую, что мозга на всех не хватает.

Уже сделал. Вынес базу на нормльную ФС, дал много памяти, теперь результаты стабильнее :)

А индексов нет. (Писал не я, есть некие причины)