Est-il nécessaire de créer un index séparé pour la colonne du champ de partition MySQL ?

Tout le monde sait que le champ de partition doit faire partie de la clé primaire. Ainsi, après avoir créé la clé primaire composite, est-il nécessaire d'ajouter un index distinct pour le champ de partition ? Est-ce efficace ? Cet article vous présente principalement les informations pertinentes sur la nécessité de créer un index séparé pour la colonne du champ de partition MySQL. L'article est vérifié à l'aide d'exemples et a une certaine valeur d'apprentissage de référence pour la compréhension et l'apprentissage de tous les amis qui en ont besoin. petit Apprenons ensemble.

1. Créez une nouvelle table effect_new (partitionnée par mois en fonction de l'heure de création)

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, Insérez quelques données,

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. >

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

Le résultat est :

4. à la table effect_new 🎜>

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

5. Analysez le plan d'exécution après avoir ajouté l'index

Le résultat est :

6. Conclusion :

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

Bien que la table soit déjà partitionnée en fonction de ce champ, cela ne peut pas être assimilé à un index. Après le partitionnement, on peut seulement dire que les enregistrements avec une certaine valeur dans le champ seront dans une certaine partition, mais ce n'est pas un index et il sera difficile à trouver.

Parfois, la clé primaire n'est pas égale à la colonne de base de partitionnement. À ce stade, si la clé primaire veut construire un index clusterisé, elle doit inclure la colonne de base de partitionnement pour former une clé primaire composite. Alors, dans ce cas, la colonne de partitionnement n’a-t-elle pas d’index ? Oui, mais ce n'est pas assez rapide. Si la colonne de base de partitionnement n'est pas classée en premier dans cet index composite, elle ne sera pas assez rapide. Si la colonne de base de partitionnement est souvent utilisée comme condition de filtre dans l'instruction de recherche, cela est nécessaire. pour ajouter une colonne supplémentaire à la colonne de base de partitionnement. Créez un index distinct.

Recommandations associées :

Le champ de partition de MYSQL doit être inclus dans le champ de clé primaire_MySQL

Les différents moteurs de stockage et différentes partitions de MySQL L'impact des champs sur queries_MySQL

Partition de la table de partition MySQL modification en ligne de la partition columns_MySQL

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!