I have a table with following definition.
CREATE TABLE `test` (
`a` int(11) NOT NULL,
`b` int(11) DEFAULT NULL,
`c` int(11) DEFAULT NULL,
`d` int(11) DEFAULT NULL,
`e` int(11) DEFAULT NULL,
`f` int(11) DEFAULT NULL,
`g` varchar(45) COLLATE utf8_unicode_ci DEFAULT NULL,
`h` varchar(45) COLLATE utf8_unicode_ci DEFAULT NULL,
PRIMARY KEY (`a`),
UNIQUE KEY `b_UNIQUE` (`b`),
KEY `single` (`c`),
KEY `double` (`d`,`e`),
KEY `triple` (`f`,`g`,`h`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci
For some queries when I check optimizer trace I notice key parts for indices.
For example:
{
"index": "single",
"usable": true,
"key_parts": [
"c",
"a"
]
},
{
"index": "double",
"usable": true,
"key_parts": [
"d",
"e",
"a"
]
}
Notice for indices single
and double
the key part contains the Primary Key a
at the end. That is what InnoDB
says. So thats good.
{
"index": "b_UNIQUE",
"usable": true,
"key_parts": [
"b"
]
}
But as seen in above snippet, the b_Unique
key does not contain primary key a
as the final key part. Is it really not present and pointer to record is present? What implications does this have with respect to query optimization and Page reorganisation?
EDIT 1: It seems to be present in MySQL 8.0 version. It is highly likely to be present in MySQL version 5.7 as well. So require a way to check its presence in this version.