Подтвердить что ты не робот

MySQL медленный запрос - "Ожидание блокировки кеша запроса"

Я запускаю простой запрос в простой таблице на том же компьютере, что и сервер с 5.5. Он принимает 22 сек для возврата ~ 7000 строк из таблицы из 20 миллионов строк. При профилировании большая часть времени используется несколькими "Ожидание блокировки кеша запросов". Что такое "Ожидание блокировки кеша запроса" и почему этот запрос занимает так много времени? Это что-то с тем, как я настроил сервер?

Вот профиль (обратите внимание, что время для операции на самом деле указано в строке ниже, как указано здесь):

mysql> show profile for query 4;
+--------------------------------+----------+
| Status                         | Duration |
+--------------------------------+----------+
| starting                       | 0.000015 |
| Waiting for query cache lock   | 0.000003 |
| checking query cache for query | 0.000045 |
| checking permissions           | 0.000006 |
| Opening tables                 | 0.000027 |
| System lock                    | 0.000007 |
| Waiting for query cache lock   | 0.000032 |
| init                           | 0.000018 |
| optimizing                     | 0.000008 |
| statistics                     | 0.033109 |
| preparing                      | 0.000019 |
| executing                      | 0.000002 |
| Sending data                   | 4.575480 |
| Waiting for query cache lock   | 0.000005 |
| Sending data                   | 5.527728 |
| Waiting for query cache lock   | 0.000005 |
| Sending data                   | 5.743041 |
| Waiting for query cache lock   | 0.000004 |
| Sending data                   | 6.191706 |
| end                            | 0.000007 |
| query end                      | 0.000005 |
| closing tables                 | 0.000028 |
| freeing items                  | 0.000008 |
| Waiting for query cache lock   | 0.000002 |
| freeing items                  | 0.000182 |
| Waiting for query cache lock   | 0.000002 |
| freeing items                  | 0.000002 |
| storing result in query cache  | 0.000004 |
| logging slow query             | 0.000001 |
| logging slow query             | 0.000002 |
| cleaning up                    | 0.000003 |
+--------------------------------+----------+

Вот таблица:

mysql> SHOW CREATE TABLE prvol;

"Table","Create Table"
"prvol","CREATE TABLE `prvol` (
  `ticker` varchar(10) DEFAULT NULL,
  `date` date DEFAULT NULL,
  `close` float unsigned DEFAULT NULL,
  KEY `Index 1` (`date`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1"

Вот запрос:

mysql> select close from prvol where date = '20100203';

EDIT: После запуска с SQL_NO_CACHE все время выполняется. Может ли это быть нормальным для таблицы такого размера на 2,4 ГГц, 3 ГБ оперативной памяти?

+----------------------+-----------+
| Status               | Duration  |
+----------------------+-----------+
| starting             |  0.000052 |
| checking permissions |  0.000007 |
| Opening tables       |  0.000027 |
| System lock          |  0.000008 |
| init                 |  0.000019 |
| optimizing           |  0.000008 |
| statistics           |  0.034766 |
| preparing            |  0.000011 |
| executing            |  0.000002 |
| Sending data         | 22.071324 |
| end                  |  0.000012 |
| query end            |  0.000005 |
| closing tables       |  0.000020 |
| freeing items        |  0.000170 |
| logging slow query   |  0.000001 |
| logging slow query   |  0.000003 |
| cleaning up          |  0.000004 |
+----------------------+-----------+

РЕДАКТИРОВАТЬ: Включить результаты объяснения.

mysql> explain extended select cp from prvol where date = '20100208';
+----+-------------+-------+------+---------------+---------+---------+-------+------+----------+-------------+
| id | select_type | table | type | possible_keys | key     | key_len | ref   |rows  | filtered | Extra       |
+----+-------------+-------+------+---------------+---------+---------+-------+------+----------+-------------+
|  1 | SIMPLE      | prvol | ref  | Index 1       | Index 1 | 4       | const |6868  |   100.00 | Using where |
+----+-------------+-------+------+---------------+---------+---------+-------+------+----------+-------------+
1 row in set, 1 warning (0.08 sec)
4b9b3361

Ответ 1

Я решил проблему с медленными запросами. Чтобы суммировать проблему, потребовалось 22 сек для запроса 7000 строк из 20-миллионной строки, индексированной таблицы 1,7 ГБ. Проблема заключалась в том, что кеш был слишком мал, и запрос приходил на диск для каждого запроса. Я бы подумал, что доступ к диску будет быстрее, чем то, что я видел, потому что я уходил с индексированного столбца, поэтому объем данных, считываемых с диска, должен был быть небольшим. Но я предполагаю, что накладные расходы на доступ к хранилищу InnoDB на диске очень много.

Как только я установил innodb_buffer_pool_size=1024M в файл my.ini, первоначальный запрос займет много времени, но все последующие запросы будут завершены в течение секунды.

К сожалению, профилирование действительно не помогло.