Ist es notwendig, einen separaten Index für die MySQL-Partitionsfeldspalte zu erstellen?

Jeder weiß, dass das Partitionsfeld Teil des Primärschlüssels sein muss. Ist es also notwendig, nach der Erstellung des zusammengesetzten Primärschlüssels einen separaten Index für das Partitionsfeld hinzuzufügen? Ist es effektiv? Dieser Artikel stellt Ihnen hauptsächlich die relevanten Informationen darüber vor, ob es notwendig ist, einen separaten Index für die MySQL-Partitionsfeldspalte zu erstellen. Der Artikel wird anhand von Beispielen überprüft und hat einen bestimmten Referenz-Lernwert für alle, die ihn verstehen und lernen müssen klein Lasst uns gemeinsam lernen.

1. Erstellen Sie eine neue Tabelle effect_new (partitioniert nach Monat basierend auf der Erstellungszeit)

CREATE TABLE `effect_new` (
 `id` bigint(20) NOT NULL AUTO_INCREMENT,
 `type` tinyint(4) NOT NULL DEFAULT '0',
 `timezone` varchar(10) DEFAULT NULL,
 `date` varchar(10) NOT NULL,
 `hour` varchar(2) DEFAULT NULL,
 `position` varchar(200) DEFAULT NULL,
 `country` varchar(32) NOT NULL,
 `create_time` datetime NOT NULL DEFAULT '1970-01-01 00:00:00',
 PRIMARY KEY (`id`,`create_time`),
 KEY `index_date_hour_coun` (`date`,`hour`,`country`)
) ENGINE=InnoDB AUTO_INCREMENT=983041 DEFAULT CHARSET=utf8
PARTITION BY RANGE (TO_DAYS (`create_time`))
(PARTITION p0 VALUES LESS THAN (736754) ENGINE = InnoDB,
 PARTITION p1 VALUES LESS THAN (736785) ENGINE = InnoDB,
 PARTITION p2 VALUES LESS THAN (736815) ENGINE = InnoDB,
 PARTITION p3 VALUES LESS THAN (736846) ENGINE = InnoDB,
 PARTITION p4 VALUES LESS THAN (736876) ENGINE = InnoDB,
 PARTITION p5 VALUES LESS THAN (736907) ENGINE = InnoDB,
 PARTITION p6 VALUES LESS THAN (736938) ENGINE = InnoDB,
 PARTITION p7 VALUES LESS THAN (736968) ENGINE = InnoDB,
 PARTITION p8 VALUES LESS THAN (736999) ENGINE = InnoDB,
 PARTITION p9 VALUES LESS THAN (737029) ENGINE = InnoDB,
 PARTITION p10 VALUES LESS THAN (737060) ENGINE = InnoDB);

2 , Geben Sie einige Daten ein,

INSERT INTO `effect_new` (`id`, `type`, `timezone`, `date`, `hour`, `position`, `country`, `create_time`) VALUES ('1', '0', 'GMT+8', '2017-07-01', '', 'M-NotiCleanFull-FamilyRecom-0026', '', '2017-07-02 00:07:02');
INSERT INTO `effect_new` (`id`, `type`, `timezone`, `date`, `hour`, `position`, `country`, `create_time`) VALUES ('2', '1', 'GMT+8', '2017-09-30', '23', 'Ma5dtJub', 'EG', '2017-10-01 00:00:00');
INSERT INTO `effect_new` (`id`, `type`, `timezone`, `date`, `hour`, `position`, `country`, `create_time`) VALUES ('3', '1', 'GMT+8', '2017-09-10', '10', '28', 'DZ', '2017-09-11 00:08:20');
INSERT INTO `effect_new` (`id`, `type`, `timezone`, `date`, `hour`, `position`, `country`, `create_time`) VALUES ('4', '1', 'GMT+8', '2017-02-03', '20', '32', 'AD', '2017-02-04 00:00:00');
INSERT INTO `effect_new` (`id`, `type`, `timezone`, `date`, `hour`, `position`, `country`, `create_time`) VALUES ('5', '0', 'GMT+8', '2017-03-05', '2', NULL, 'AI', '2017-03-06 02:10:00');
INSERT INTO `effect_new` (`id`, `type`, `timezone`, `date`, `hour`, `position`, `country`, `create_time`) VALUES ('6', '0', 'GMT+8', '2017-09-23', '13', 'M-BrandSplash-S-0038', 'AG', '2017-09-23 13:00:00');
INSERT INTO `effect_new` (`id`, `type`, `timezone`, `date`, `hour`, `position`, `country`, `create_time`) VALUES ('7', '1', NULL, '2017-10-13', '12', 'BB-Main-AppAd-0018', 'AF', '2017-10-14 12:00:00');
INSERT INTO `effect_new` (`id`, `type`, `timezone`, `date`, `hour`, `position`, `country`, `create_time`) VALUES ('8', '0', 'GMT+8', '2017-10-28', '2', 'M-ChargeReminder-S-0040', 'AE', '2017-10-29 00:00:00');
INSERT INTO `effect_new` (`id`, `type`, `timezone`, `date`, `hour`, `position`, `country`, `create_time`) VALUES ('9', '1', 'GMT+8', '2017-10-09', NULL, '30', 'AI', '2017-10-10 00:09:00');
INSERT INTO `effect_new` (`id`, `type`, `timezone`, `date`, `hour`, `position`, `country`, `create_time`) VALUES ('10', '0', 'GMT+8', '2017-10-05', '5', ' M-BrandSplash', 'LA', '2017-10-06 05:10:00');

3. Analyseerklärung

EXPLAIN PARTITIONS
select * from effect_new_index
where create_time = '2017-10-14 12:00:00'

Das Ergebnis ist:

id	select_type	table	partitions	tpye	possible_keys	key	key_len	ref	rows	filtered	extra
1	SIMPLE	effect_new	p8	ALL	null	null	null	null	391515	10	Using where

Index idx_ctime hinzufügen

5. Analysieren Sie den Ausführungsplan nach dem Hinzufügen des Index

Das Ergebnis ist:

id	select_type	table	partitions	tpye	possible_keys	key	key_len	ref	rows	filtered	extra
1	SIMPLE	effect_new	p8	ref	idx_ctime	idx_ctime	5	const	60760	100	null

6. Fazit:

Während die Tabelle bereits basierend auf diesem Feld partitioniert ist, kann dies nicht mit einem Index gleichgesetzt werden. Nach der Partitionierung kann nur gesagt werden, dass sich Datensätze mit einem bestimmten Wert im Feld in einer bestimmten Partition befinden. Dies ist jedoch kein Index und daher schwer zu finden.

Manchmal stimmt der Primärschlüssel nicht mit der Partitionierungsbasisspalte überein. Wenn der Primärschlüssel zu diesem Zeitpunkt einen Clustered-Index erstellen möchte, muss er die Partitionierungsbasisspalte enthalten, um einen zusammengesetzten Primärschlüssel zu bilden. Verfügt die Partitionierungsspalte in diesem Fall also nicht über einen Index? Ja, aber es ist nicht schnell genug, wenn die Partitionierungsbasisspalte in diesem zusammengesetzten Index nicht an erster Stelle steht. Wenn die Partitionierungsbasisspalte häufig als Filterbedingung in der Suchanweisung verwendet wird, ist dies erforderlich um eine zusätzliche Spalte zur Partitionierungsbasisspalte hinzuzufügen. Erstellen Sie einen separaten Index.

Verwandte Empfehlungen:

Das Partitionsfeld von MySQL muss im Primärschlüsselfeld_MySQL enthalten sein

Die verschiedenen Speicher-Engines und Partitionen von MySQL Die Auswirkungen von Feldern auf Abfragen_MySQL

MySQL-Partitionstabellenpartition Online-Änderung von Partitionsfeldern_MySQL

Das obige ist der detaillierte Inhalt vonIst es notwendig, einen separaten Index für die MySQL-Partitionsfeldspalte zu erstellen?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!