У меня есть таблица с этой схемой:
CREATE TABLE 'data_realtime' (
'id' mediumint(9) unsigned NOT NULL AUTO_INCREMENT,
'timestamp' int(10) NOT NULL,
'ticker_id' smallint(5) unsigned NOT NULL,
'price' decimal(7,2) unsigned NOT NULL,
'volume' mediumint(9) unsigned NOT NULL,
'bid' decimal(7,2) unsigned DEFAULT NULL,
'bid_sz' smallint(6) unsigned DEFAULT NULL,
'ask' decimal(7,2) unsigned DEFAULT NULL,
'ask_sz' smallint(6) unsigned DEFAULT NULL,
PRIMARY KEY ('id'),
UNIQUE KEY 'ticker_timestamp' ('ticker_id','timestamp') USING BTREE,
CONSTRAINT 'data_realtime_ibfk_2' FOREIGN KEY ('ticker_id') REFERENCES 'tickers' ('id') ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=11330043 DEFAULT CHARSET=latin1
Я пытаюсь запустить простой запрос для упорядочения данных по метке времени:
select * from data_realtime ORDER BY timestamp ASC
Это занимает 2,5 с (для строк ~ 4.5M, которые в итоге увеличатся до примерно 12M строк). Но если я просто запускаю
select * from data_realtime
требуется.25 с
У меня есть сводный индекс в timestamp (с тикером_id), который, как я думал, поможет решить эту проблему.
Что я могу сделать для повышения производительности при заказе?
Благодарю.
EDIT: Чтобы добавить к исходной проблеме, у меня есть этот запрос:
SELECT data_latest.*, data_1m.timestamp timestamp_1m, data_1m.price price_1m, data_1m.volume volume_1m FROM
(SELECT B.* FROM
(SELECT ticker_id, max(timestamp) max_timestamp FROM 'data_rt' GROUP BY ticker_id)
A
LEFT JOIN
data_rt B
ON
A.ticker_id=B.ticker_id
and A.max_timestamp=B.timestamp)
data_latest
LEFT JOIN
data_rt data_1m
ON
data_latest.timestamp <= (data_1m.timestamp + (60*1) )
AND data_latest.timestamp > (data_1m.timestamp + 60*(1-0.5))
AND data_latest.timestamp>data_1m.timestamp
AND data_latest.ticker_id=data_1m.ticker_id
ORDER BY data_1m.timestamp ASC
На наборе 1M строк он занимает около 1,3 с. Добавление последнего ORDER BY - это то, что значительно увеличивает время. Если я вместо ORDER BY timestamp занимает всего 0.05s.
Что я могу улучшить при сортировке с использованием столбца temp?
Индексирование может помочь ускорить запросы; но только тогда, когда индексы являются теми, которые MySQL будет использовать. Композитные индексы, такие как индекс на (a
, b
), помогут в запросах, связанных с a
и b
вместе; например, с WHERE a = N AND b = M
или ORDER BY a, b
. Такой индекс будет даже помогать в запросах с участием только a
. В принципе, любой составной индекс (a, b,.... n)
также действует как индексы (a, b,.... n-1)
, (a, b,.... n-2)
... (a, b)
и (a)
.
Однако, примените их применимость в широких пределах в зависимости от фактических значений данных (см. Мой второй комментарий к самому вопросу); они не могут использоваться для последних полей в индексе, когда более ранние не задействованы. IE (a, b)
не используется, когда запросы включают только b
. _ (a,b,c,...,n)
может и часто будет использоваться для запросов, связанных с (a,b,n)
но будет функционировать так же эффективно, как индекс (a,b)
.