Same query on local/live site, vastly different performance - mysql

Question

My slow query log is showing 5,6+ second runs randomly of a seemingly normal query. Running the same query on my local clone of the site gives a 0.05s query run time. Here is the EXPLAIN of both:
I'm a bit dense when it comes to MySQL optimization but, I don't understand how this can give such different results? The tables are roughly the same, the live site is more updated but otherwise very similar.
Edit:
Instead of comparing to my local installation, I instead am comparing to my "old" live server. I just moved servers this morning.
The OLD server DDL of the table:
CREATE TABLE `wp_bp_activity` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`user_id` bigint(20) NOT NULL,
`component` varchar(75) COLLATE utf8mb4_unicode_ci NOT NULL,
`type` varchar(75) COLLATE utf8mb4_unicode_ci NOT NULL,
`action` text COLLATE utf8mb4_unicode_ci NOT NULL,
`content` longtext COLLATE utf8mb4_unicode_ci NOT NULL,
`primary_link` text COLLATE utf8mb4_unicode_ci NOT NULL,
`item_id` bigint(20) NOT NULL,
`secondary_item_id` bigint(20) DEFAULT NULL,
`date_recorded` datetime NOT NULL,
`hide_sitewide` tinyint(1) DEFAULT 0,
`mptt_left` int(11) NOT NULL DEFAULT 0,
`mptt_right` int(11) NOT NULL DEFAULT 0,
`is_spam` tinyint(1) NOT NULL DEFAULT 0,
PRIMARY KEY (`id`),
KEY `date_recorded` (`date_recorded`),
KEY `user_id` (`user_id`),
KEY `item_id` (`item_id`),
KEY `secondary_item_id` (`secondary_item_id`),
KEY `component` (`component`),
KEY `type` (`type`),
KEY `mptt_left` (`mptt_left`),
KEY `mptt_right` (`mptt_right`),
KEY `hide_sitewide` (`hide_sitewide`),
KEY `is_spam` (`is_spam`),
FULLTEXT KEY `content` (`content`)
) ENGINE=InnoDB AUTO_INCREMENT=1060622 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
The NEW server DDL:
CREATE TABLE `wp_bp_activity` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`user_id` bigint(20) NOT NULL,
`component` varchar(75) COLLATE utf8mb4_unicode_ci NOT NULL,
`type` varchar(75) COLLATE utf8mb4_unicode_ci NOT NULL,
`action` text COLLATE utf8mb4_unicode_ci NOT NULL,
`content` longtext COLLATE utf8mb4_unicode_ci NOT NULL,
`primary_link` text COLLATE utf8mb4_unicode_ci NOT NULL,
`item_id` bigint(20) NOT NULL,
`secondary_item_id` bigint(20) DEFAULT NULL,
`date_recorded` datetime NOT NULL,
`hide_sitewide` tinyint(1) DEFAULT 0,
`mptt_left` int(11) NOT NULL DEFAULT 0,
`mptt_right` int(11) NOT NULL DEFAULT 0,
`is_spam` tinyint(1) NOT NULL DEFAULT 0,
PRIMARY KEY (`id`),
KEY `date_recorded` (`date_recorded`),
KEY `user_id` (`user_id`),
KEY `item_id` (`item_id`),
KEY `secondary_item_id` (`secondary_item_id`),
KEY `component` (`component`),
KEY `type` (`type`),
KEY `mptt_left` (`mptt_left`),
KEY `mptt_right` (`mptt_right`),
KEY `hide_sitewide` (`hide_sitewide`),
KEY `is_spam` (`is_spam`),
FULLTEXT KEY `content` (`content`)
) ENGINE=InnoDB AUTO_INCREMENT=1060840 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
They are the same, but as you can see at the bottom of each the number of rows (by the AUTO_INCREMENT). They are very similar. As I said this OLD server was active this morning, so there are many recent datetimes here as well.
Running the query pictured above on both servers however, results in the same difference in "EXPLAIN" output, the NEW server is examining an insane amount of rows in 10x the time.

Answer 1

Use a "composite" index (in this order):
INDEX(is_spam, hide_sitewide, type)
Tip: When EXPLAIN says "Intersect", you need a composite index.
Get rid of a.type NOT IN ... since that test is already handled by a.type IN ...
Get rid of DISTINCT, it may be causing an extra pass to de-dup.
Use EXPLAIN FORMAT=JSON SELECT ... to get more detailed info.
Use text, not images, in this forum.
There may be a difference in version between the two servers -- and this may explain the different optimization technique used (or mis-used).