MySql indexes are created after the partition table queries and even accelerate single-table query

Disclaimer: This article is a blogger original article, follow the CC 4.0 BY-SA copyright agreement, reproduced, please attach the original source link and this statement.
This link: https: //blog.csdn.net/konkon2012/article/details/96482548
order to speed up queries, we usually create an index based on Where conditions! Then the partition and then create an index, it should be faster!

We based order form and order merchandise table, for example, first create the table structure:

CREATE TABLE `zstb_orders` (
`order_id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
`org_id` INT(10) UNSIGNED NOT NULL,
`order_money` DECIMAL(6,2) UNSIGNED NOT NULL DEFAULT '0.00',
PRIMARY KEY (`order_id`,`org_id`),
KEY `order_id` (`order_id`)
) ENGINE=INNODB DEFAULT CHARSET=utf8;

CREATE TABLE `zstb_orders_goods` (
`order_id` INT(10) UNSIGNED NOT NULL DEFAULT '0',
`org_id` INT(10) UNSIGNED NOT NULL DEFAULT '0',
`goods_id` INT(10) UNSIGNED NOT NULL DEFAULT '0',
`goods_name` VARCHAR(20) DEFAULT '',
PRIMARY KEY (`order_id`,`org_id`,`goods_id`)
) ENGINE=INNODB DEFAULT CHARSET=utf8;

　　

We partition the two tables through `org_id`, the script is as follows:

ALTER TABLE `zstb_orders` PARTITION BY RANGE(`org_id`) (
PARTITION p1 VALUES LESS THAN (100),
PARTITION p2 VALUES LESS THAN (200),
PARTITION p3 VALUES LESS THAN (300),
PARTITION p4 VALUES LESS THAN (400),
PARTITION p5 VALUES LESS THAN MAXVALUE 
);
ALTER TABLE `zstb_orders_goods` PARTITION BY RANGE(`org_id`) (
PARTITION p1 VALUES LESS THAN (100),
PARTITION p2 VALUES LESS THAN (200),
PARTITION p3 VALUES LESS THAN (300),
PARTITION p4 VALUES LESS THAN (400),
PARTITION p5 VALUES LESS THAN MAXVALUE 
);

　　

As to why you want to use 'org_id' to partition in question is not discussed in this article, you can use other fields to be partitioned according to your own needs.

Then insert a few data:

INSERT INTO `zstb_orders`(`order_id`, `org_id`, order_money) VALUES (1, 50, 200);
INSERT INTO `zstb_orders_goods`(`order_id`,`org_id`,`goods_id`,`goods_name`) VALUES (1, 50, 1, '酸奶');
INSERT INTO `zstb_orders_goods`(`order_id`,`org_id`,`goods_id`,`goods_name`) VALUES (1, 50, 2, '纯奶');

INSERT INTO `zstb_orders`(`order_id`, `org_id`, order_money) VALUES (2, 150, 200);
INSERT INTO `zstb_orders_goods`(`order_id`,`org_id`,`goods_id`,`goods_name`) VALUES (2, 150, 1, '酸奶');
INSERT INTO `zstb_orders_goods`(`order_id`,`org_id`,`goods_id`,`goods_name`) VALUES (2, 150, 2, '纯奶');

INSERT INTO `zstb_orders`(`order_id`, `org_id`, order_money) VALUES (3, 350, 200);
INSERT INTO `zstb_orders_goods`(`order_id`,`org_id`,`goods_id`,`goods_name`) VALUES (3, 350, 1, '酸奶');
INSERT INTO `zstb_orders_goods`(`order_id`,`org_id`,`goods_id`,`goods_name`) VALUES (3, 350, 2, '纯奶');

　　

Next we analyze the query:

EXPLAIN PARTITIONS SELECT * FROM `zstb_orders` WHERE org_id = 150;

　　

When the order query the table, we found that although only Scan 'p2' partition, but does not use the primary key index, a little disappointed.

Similarly, we also order items table analysis:

EXPLAIN PARTITIONS SELECT * FROM `zstb_orders_goods` WHERE org_id = 150;

　　

Or only the scan results 'p2' partition, and does not use the primary key index.

Let us try to analyze even the table query:

EXPLAIN PARTITIONS SELECT * FROM `zstb_orders` AS o JOIN `zstb_orders_goods` AS g ON o.order_id = g.order_id WHERE o.org_id = 150;

　　

Queries on the main table 'zstb_orders' although only Scan 'p2' partition, but not using the primary key index.

Even on the table 'zstb_orders_goods' query is to scan the entire table, but using the primary key index, why not scan specific partition table it?

EXPLAIN PARTITIONS SELECT * FROM `zstb_orders` AS o JOIN `zstb_orders_goods` AS g ON o.order_id = g.order_id AND o.org_id = g.org_id WHERE o.org_id = 150;

　　

Consider 'zstb_orders_goods' is partitioned by 'org_id', but even the time-table query, did not specify on 'org_id', we just need to query related conditions

The above increase 'org_id' can be associated, as follows:

 

The main table query does not change, even the table 'zstb_orders_goods' inquiry found, although the partition table 'p2', but the index has lost!

So, if at the same time we need to create partitions, but also use the index, it was re-created.

ALTER TABLE `zstb_orders_goods` ADD INDEX org_id_index(`org_id`);

　　

After you've created, we first look at the case of single-table query:

EXPLAIN PARTITIONS SELECT * FROM `zstb_orders_goods` WHERE org_id = 150;

　　

Although just scanned 'p2' partition, but does not use the index, after this time we create an index, it was using it, OK!

In the analysis of even just query the table:

EXPLAIN PARTITIONS SELECT * FROM `zstb_orders` AS o JOIN `zstb_orders_goods` AS g ON o.order_id = g.order_id AND o.org_id = g.org_id WHERE o.org_id = 150;

　　

That scan the partition table, but also to use the index!

Of course, if you want to master table 'zstb_orders' when queried also use the index, then we also need to 'zstb_orders' create 'org_id' index can be.
----------------
Disclaimer: This article is CSDN blogger "program ape the roaring 'original article, follow the CC 4.0 BY-SA copyright agreement, reproduced, please attach the original source link and this statement.
Original link: https: //blog.csdn.net/konkon2012/article/details/96482548