2016-09-17 8 views
-1

У меня есть таблица innoDB с названием «transaction» с ~ 1,5 миллиона строк. Я хотел бы разделить эту таблицу (возможно, на колонку «gas_station_id», поскольку он используется много в присоединиться запросы), но я прочитал в MySQL 5.7 Reference Manual чтоне могу разбить эту таблицу mysql

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

У меня есть два вопроса:

  1. Колонка «gas_station_id» не является частью уникального ключа или первичного ключа. Как я могу разбить эту таблицу?
  2. , даже если бы я мог разбить эту таблицу, я не уверен, какой тип разбиения будет лучше в этом случае? (Я думал о разделении LIST (у нас есть около 40 различных (отдельных) заправочных станций), но я не уверен, так как в каждом списке есть только одно значение: ALTER TABLE transaction PARTITION BY LIST(gas_station_id) (PARTITION p1 VALUES IN (9001), PARTITION p2 VALUES IN (9002),.....)
  3. Я пробовал разбивку на KEY , но я получаю следующее сообщение об ошибке (я думаю, потому что идентификатор не является частью всех уникальных ключей ..):

# 1053 - уникальный индекс должен включать в себя все столбцы в функции секционирования стола

Это конструктор е таблицы "сделки":

enter image description here

EDIT и это то, что SHOW CREATE TABLE показывает:

CREATE TABLE `transaction` (
`id` int(11) NOT NULL AUTO_INCREMENT, 
`terminal_transaction_id` int(11) NOT NULL, 
`fuel_terminal_id` int(11) NOT NULL, 
`fuel_terminal_serial` int(11) NOT NULL, 
`xboard_id` int(11) NOT NULL, 
`gas_station_id` int(11) NOT NULL, 
`operator_id` varchar(16) NOT NULL, 
`shift_id` int(11) NOT NULL, 
`xboard_total_counter` int(11) NOT NULL, 
`fuel_type` tinyint(2) NOT NULL, 
`start_fuel_time` int(11) NOT NULL, 
`end_fuel_time` int(11) DEFAULT NULL, 
`preset_amount` int(11) NOT NULL, 
`actual_amount` int(11) DEFAULT NULL, 
`fuel_cost` int(11) DEFAULT NULL, 
`payment_cost` int(11) DEFAULT NULL, 
`purchase_type` int(11) NOT NULL, 
`payment_ref_id` text, 
`unit_fuel_price` int(11) NOT NULL, 
`fuel_status_id` int(11) DEFAULT NULL, 
`fuel_mode_id` int(11) NOT NULL, 
`payment_result` int(11) NOT NULL, 
`card_pan` varchar(20) DEFAULT NULL, 
`state` int(11) DEFAULT NULL, 
`totalizer` int(11) NOT NULL DEFAULT '0', 
`shift_start_time` int(11) DEFAULT NULL, 
PRIMARY KEY (`id`), 
UNIQUE KEY `terminal_transaction_id` (`terminal_transaction_id`,`fuel_terminal_id`,`start_fuel_time`) USING BTREE, 
KEY `start_fuel_time_idx` (`start_fuel_time`), 
KEY `fuel_terminal_idx` (`fuel_terminal_id`), 
KEY `xboard_idx` (`xboard_id`), 
KEY `gas_station_id` (`gas_station_id`) USING BTREE, 
KEY `purchase_type` (`purchase_type`) USING BTREE, 
KEY `shift_start_time` (`shift_start_time`) USING BTREE, 
KEY `fuel_type` (`fuel_type`) USING BTREE 
) ENGINE=InnoDB AUTO_INCREMENT=1665335 DEFAULT CHARSET=utf8 ROW_FORMAT=COMPACT 
+1

Если таблица имеет миллиард строк, берегитесь. 'id INT SIGNED' ограничен примерно 2 миллиардами. –

+1

Многие из этих 'INTs' не должны быть полными 4 байтами; сокращают их до космического пространства, тем самым улучшая кешируемость, следовательно, лучшую скорость. –

ответ

1

Короткий ответ: Не используйте PARTITION. Давайте посмотрим на запрос, чтобы ускорить его.

Длинный ответ:

  • 1.5M строки лишь незначительно достаточно большой, чтобы рассмотреть разделение.
  • PARTITION BY LIST, вероятно, бесполезен для работы.
  • Вы не дали достаточно информации, чтобы дать вам ответы на другие туманные намеки. Пожалуйста, предоставьте не менее SHOW CREATE TABLE и медленный SELECT.
  • К ключу PRIMARY или UNIQUE можно добавить ключ раздела; вы потеряете тест на уникальность.
  • Не индексируйте столбец с низкой мощностью; он не будет использоваться.

More on PARTITION

+0

Спасибо Рик за вашу помощь. Я редактировал свой вопрос и добавил 'SHOW CREATE TABLE'. Фактически на данный момент таблица транзакций имеет 1.5M строк.У нас будет аналогичная таблица с гораздо большим количеством записей (около 1 миллиарда строк). Я увеличил 'innodb_buffer_pool_size', и теперь запросы выполняются намного быстрее, но я не уверен, будет ли достаточно изменять эту переменную для большей таблицы, которую мы будем иметь в ближайшем будущем. поэтому я думал о разделении этой таблицы. – mOna

+0

Buff_pool - важный фактор производительности; он должен составлять около 70% доступной ОЗУ. –

+0

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