I have the following table (tracking searches):
CREATE TABLE `searches` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`deleted` tinyint(1) unsigned NOT NULL,
`query` varchar(1024) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`userId` int(10) unsigned NOT NULL,
`connectionId` int(10) unsigned NOT NULL,
`pluginId` int(10) unsigned NOT NULL,
PRIMARY KEY (`id`),
KEY `key,deleted` (`publicId`,`deleted`),
KEY `deleted,userId` (`deleted`,`userId`),
KEY `deleted,connectionId,pluginId` (`deleted`,`connectionId`,`pluginId`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
Sometimes, I run queries to return all the queries done by a specific user. In that case, I have an index with the following columns: deleted
,userId
Other times, I run queries to return all the queries done by specific "connection" and "plugin". In that case, I have an index with the following columns: deleted
,connectionId
,pluginId
The size of the indexes are growing substantially, and so I'm trying to understand how I could better optimize these.
Would there be value in combine both indexes into one? For example, it would have the following columns: deleted
,userId
,connectionId
,pluginId
I'm not sure if this would result in a smaller index while fulfilling the queries in a acceptable with.
deleted
the leading column? It's by far, presumably, the least selective.deleted
column, you may consider partitioning the table. Thus you would always either select in the deleted or undeleted part of the data and wouldn't have to include this in any index. dev.mysql.com/doc/refman/8.0/en/partitioning.html