Выбор первичного ключа, суррогатный ключ, индекс в базе данных MySQL акций

Question

Тип базы данных: MySQL

Столбцы: дата, время, цена1, QTY1, PROCE2, QTY2 Время будет в миллисекундном количестве записей примерно 5,5 млн. В течение месяца.

Я не могу выбрать дату в качестве первичного ключа, поскольку она не уникальна, но могу выбрать дату и время в сочетании, но это также не очень хорошая идея.

Я буду запускать запросы, такие как Select Price и QUTY между «этой датой и временем» и «датой и временем», и результат может быть в диапазоне миллионов.

Что может быть лучшим выбором с точки зрения первичного ключа, индекса и суррогатного ключа и того, что является лучшим способом реализовать это. Как мне оптимизировать базу данных.

Answer 1

Не уверен, почему вы говорите, что выбор как даты, так и времени будет плохой идеей (вы против составных ключей?)

Большая проблема для вас заключается в том, что время не хранит миллисекунды. Смотрите эту ошибку для получения дополнительной информации об этом: http://bugs.mysql.com/bug.php?id=8523

Кроме того, кажется, что в ключе не хватает чего -то, что идентифицирует акции, такой как тикер. Поскольку тикер может измениться со временем, было бы неплохо представить суррогат для него, такой как стоко. Вы бы сделали это в таблице, называемом запасом или аналогичным.

Затем для вашей торговой таблицы я бы посоветовал использовать Stocid, дату и время (но сохранить время в чем -то другое, кроме времени DataType, чтобы вы могли хранить миллисекунды. Задайте другой вопрос, если вам нужна помощь в этом).

Порядок ключей в PK важен как для хранения, так и для репрессии. Для поиска вы хотите сначала положить самые избирательные ключи для вашего запроса. Поэтому, если вы склонны получить доступ ко всем данным для акций одновременно (или для набора акций), поместите Stockid сначала, чтобы индекс был использован для их быстрого поиска. Если вы склонны получить доступ ко всем данным для данного интервала, поместите дату, затем сначала время.

Для хранения лучше добавлять, чтобы сначала иметь дату и время - хорошая идея.

Если вы хотите получить доступ в основном в диапазонах дат, но иногда на складе поместите вторичный индекс на Stocid.

Answer 2

Поскольку у вас нет естественного ключа (так что в каждой строке нет ничего уникального), вам нужно добавить суррогатный ключ (ради аргумента "TransactionId"). Вы все еще можете иметь свой индекс в зависимости от времени даты (что на самом деле действительно должно быть единым столбцом) для эффективного сканирования периода.