Поскольку data_timestamp
на самом деле было BIGINT
, вам не разрешено использовать функции даты. Казалось, было две ошибки, и это, вероятно, исправляет их:
ALTER TABLE geo_data
PARTITION BY RANGE (data_timestamp)
(
PARTITION p2018 VALUES LESS THAN (UNIX_TIMESTAMP('2018-01-01') * 1000),
PARTITION p2019 VALUES LESS THAN (UNIX_TIMESTAMP('2019-01-01') * 1000),
PARTITION pmax VALUES LESS THAN MAXVALUE
);
Я предполагаю, что ваши data_timestamp
действительно миллисекунды, а-ля Java? Если нет, решите, что делать с * 1000
.
SUBPARTITIONs
бесполезны; не беспокойся с ними. Если вы действительно хотите разделить по месяцам или кварталам, просто сделайте это на уровне PARTITION
.
Рекомендация: не более 50 разделов.
Сколько у вас "драйверов"? Я подозреваю, что у вас нет триллионов. Так что не используйте вслепую BIGINT
для идентификаторов. Каждый занимает 8 байтов. Например, SMALLINT UNSIGNED
будет занимать всего 2 байта и разрешать драйверы 64 КБ (и т. Д.).
Если X
и Y
- широта и долгота, возможно, было бы понятнее назвать их таковыми. Здесь - какой тип данных использовать вместо 8-байтового DOUBLE
, в зависимости от разрешения, которое у вас есть (и нужно). 4 байта FLOATs
, вероятно, достаточно хороши для транспортных средств.
Таблица имеет несколько избыточных индексов; бросить их. Кроме того, обратите внимание, что если у вас INDEX(a,b,c)
, избыточно иметь также INDEX(a,b)
.
См. Также мое обсуждение по разделению, особенно относящемуся к временным рядам, таким как ваш.
Хммм ... Интересно, 63 бита точности для SPEED
позволят вам записывать их, когда они идут со скоростью света?
Еще один момент: не создавайте p2019
до начала 2019 года. У вас есть pmax
на тот случай, если вы лукавите и не можете вовремя добавить этот раздел. И REORGANIZE PARTITION
, упомянутый в моем обсуждении, описывает, как оправиться от такой глупости.