Summary
Recently I encountered a slow sql, found in the course of the investigation after the index set of libraries and sub-sub-table relationship, summed up the next question.
problem
During application of the health of the inventory, we found a slow sql
follows
select brandgoodid from brandgood_0020
where userid = xxx AND
brandgoodid in("xxx1","xxx2")Table structure, sub-table in accordance with the userid .
CREATE TABLE`brandgood_0020` (
`brandgoodid` char(30) NOT NULL COMMENT ,
`user_id` int(10) unsigned DEFAULT NULL COMMENT '用户id',
`created` timestamp NULL DEFAULT CURRENT_TIMESTAMP,
`last_modified` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`deleted` bit(1) NOT NULL DEFAULT b'0',
PRIMARY KEY (`brandgoodid`),
KEY `idx_userid` (`userid`) USING BTREE,
) ENGINE=InnoDB DEFAULT CHARSET=utf8
explainIt is taking the userid found in the index, a user here are a lot of goods, and will have a lot of brandgoodid, so there may be very slow, because you want to scan a lot of index keys to filter brandgoodid value.
The primary key index to write the SQL expect people to go, rather than 'userid' index. Because with the primary key index, the primary key scanning is N times (N denotes the number of in).
analysis
Direct obvious reasons
IN this mysql query optimizer is misleading, wrong index
IN query often affect the judgment of mysql server. The main difference is the number of values IN which will affect different number of scanning lines, so often appear inconsistent index selection. Before also summed up a SQL IN necessarily take the index it
solve
Because brandgoodlid user query is defined at a certain dimension group, a group corresponding brandgood is limited, in this business, typically less than 10. So this place using the primary key index, higher efficiency. This solution is, where it is needed force indexto force away PRIMARY index.
Spread
After the sub-library sub-table index
Why entitled the index after the issue of sub-library sub-table, direct and sub-library sub-table does not matter ah?
Because when troubleshooting, made a mistake. After that the route to a specific brandgood_0020 table, according to brandgoodid directly to query the primary key index. Some believe and distributed database (cassandra), is such a clustering key + partition key index data. The key can block node clustering to partition the data, and then find the corresponding data according to the local index.
But in fact the mysql sub-library sub-table is not the same, the key sub-table is not indexed, but the client route. Responsible only to find the corresponding table. After the table is the same as single-table queries and logic.
Because the key sub-table is not indexed, but the query is necessary to take key points table, that means that after our sub-library sub-table of the index table built in large part to the joint index, sub-index table key + key .
Otherwise our query select xx from table where partition table key = xxx AND a = xxx, could not walk a joint index. You can only take a single index. Single index mysql server to be faced with the problem index selection.
Of course, it is not absolute, such as the above cases that I cited. According to this idea looked at other points table index. Sure enough, most of the indexes on the table are non-joint index, or come directly from a single copy table index. These indexes are basically useless, because all that userid index.
Index selection problem
Why mysql it would be wrong index, a detailed look at 10 | MySQL Why would sometimes choose the wrong index
We judge this case because of the number of scanning lines when a problem.