MySQL медленный запрос с некоторыми конкретными значениями (данные о запасах) - PullRequest
Новая
       18

MySQL медленный запрос с некоторыми конкретными значениями (данные о запасах)

0 голосов
/ 13 сентября 2018

У меня есть некоторые данные об акциях, как это 

+--------+---------------+------+-----+---------+-------+
| Field  | Type          | Null | Key | Default | Extra |
+--------+---------------+------+-----+---------+-------+
| date   | datetime      | YES  | MUL | NULL    |       |
| open   | decimal(20,4) | YES  |     | NULL    |       |
| close  | decimal(20,4) | YES  |     | NULL    |       |
| high   | decimal(20,4) | YES  |     | NULL    |       |
| low    | decimal(20,4) | YES  |     | NULL    |       |
| volume | decimal(20,4) | YES  |     | NULL    |       |
| code   | varchar(6)    | YES  | MUL | NULL    |       |
+--------+---------------+------+-----+---------+-------+

с тремя индексами, многостолбцовым индексом даты и кода, индексом даты и индексом кода.

Таблица большая, с 3000+ различными акциями, и каждая акция имеет минутные данные почти за десять лет.

Я хотел бы получить последнюю дату конкретной акции, поэтому я запускаю следующий sql: 

SELECT date FROM tablename WHERE code = '000001' ORDER BY date DESC LIMIT 1;

Однако этот запрос хорошо работает для большинства акций (<1 с), но имеет очень плохую производительность для некоторых конкретных акций (> 1 часа). Например, просто измените запрос на 

SELECT date FROM tablename WHERE code = '000029' ORDER BY date DESC LIMIT 1;

и кажется, что он замерзает навсегда.

Одна вещь, которую я знаю, это то, что у акции «000029» больше нет данных после 2016 года, а у «хороших» акций есть данные до вчерашнего дня, но я не уверен, что все «плохие» акции имеют эту характеристику.

1 Ответ

0 голосов
/ 30 сентября 2018

Во-первых, давайте уменьшим размер таблицы.Это поможет скорости некоторые .

  • decimal(20,4) занимает 10 байтов.Он имеет 16 знаков после запятой слева от десятичной точки;какой запас такой большой?Я не знаю, кому нужно больше 6. С другой стороны, достаточно ли 4 справа?
  • Нормализовать «код».«3000+ различных запасов» могут быть представлены 2-байтовыми SMALLINT UNSIGNED NOT NULL вместо текущих ~ 7 байтов.
  • '000029' смахивает ZEROFILL ??
  • DESCRIBE не такой описательный, как SHOW CREATE TABLE.Что такое PRIMARY KEY?Это может иметь большое значение в таблицах такого типа.
  • Не создавать столбцы NULL;сделайте их всех NOT NULL.
  • Используйте InnoDB и do имеют явный PRIMARY KEY.

Я бы ожидал, что они будут оптимальными, но мне нужночтобы увидеть более типичные запросы, чтобы быть уверенным. 

PRIMARY KEY(code, date)
INDEX(date)
...