MYSQL中的极限胶印性能问题

如何解决MYSQL中的极限胶印性能问题

Hellow.i的电影表具有200万行。i在MySQL中使用LIMIT OFFSET进行分页时存在性能问题。 我想创建带有电影分页的电影信息数据集。每页每页应有20个项目。

我的目标：我想对我的查询进行快速分页 结果（查询在索引列上具有8个或更多过滤器），并且分页应具体（假设我在 第2页，而我想转到第800000页，而无需花费大量时间。

创建电影查询表如下：

CREATE TABLE `movies` (
 `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,`adult` tinyint(1) NOT NULL,`backdrop_path` varchar(255) NOT NULL,`is_collection` tinyint(1) NOT NULL,`collection_id` int(11) NOT NULL,`budget` double NOT NULL,`geners` json NOT NULL,`imdb_id` varchar(100) NOT NULL,`themoviedb_id` varchar(255) NOT NULL,`original_language` varchar(255) NOT NULL,`original_title` varchar(255) NOT NULL,`overview` varchar(500) NOT NULL,`popularity` tinyint(4) NOT NULL,`poster_url` varchar(255) NOT NULL,`production_companies` json NOT NULL,`production_countries` json NOT NULL,`release_date` varchar(255) NOT NULL,`revenue` double NOT NULL,`runtime` tinyint(1) NOT NULL,`spoken_languages` json NOT NULL,`status` varchar(255) NOT NULL,`tagline` varchar(255) NOT NULL,`title` varchar(255) NOT NULL,`video` tinyint(1) NOT NULL,`vote_average` double NOT NULL,`vote_count` int(11) NOT NULL,`imdb_rate` double(8,2) NOT NULL,`meta_rate` int(11) NOT NULL,`rotten_rate` int(11) NOT NULL,`created_at` timestamp NULL DEFAULT NULL,`updated_at` timestamp NULL DEFAULT NULL,PRIMARY KEY (`id`),KEY `movies_themoviedb_id_index` (`themoviedb_id`),KEY `movies_imdb_rate_meta_rate_rotten_rate_index` (`imdb_rate`,`meta_rate`,`rotten_rate`),KEY `movies_runtime_title_budget_index` (`runtime`,`title`,`budget`),KEY `movies_popularity_revenue_original_title_index` (`popularity`,`revenue`,`original_title`),KEY `movies_imdb_id_index` (`imdb_id`),KEY `title` (`title`)
) ENGINE=MyISAM AUTO_INCREMENT=1345714 DEFAULT CHARSET=utf8

好吧，现在我使用2个在网络上看到的选项，我想在movies表上使用一些过滤器，并且我希望在其上进行过滤的每一列都有性能指标。

请注意，电影表中的所有数据都是相同的，因为我想每次 过滤器获取所有表以测试分页所有许多数据结果 课程在现实世界中的应用程序中可能超过一百万 带有过滤器。

我使用的选项：

1. 具有LIMIT OFFSET的分页
2. 与关键搜索者分页

选项1：

 #THIS QUERY RUN LES THAN 1 secends
 SELECT * FROM movies * FROM movies WHERE
 rotten_rate=78 AND imdb_rate=8.40 AND meta_rate=98 AND
 budget=87 AND title="some text" AND revenue=85785 AND
 popularity=700 AND title='is the same in all rows';

当我确实限制冲销补偿时，我使用如下查询：

#THIS QUERY RUN FOR SOMETHING BETWEEN 12 and 24 secends
 SELECT * FROM movies * FROM movies WHERE
 rotten_rate=78 AND imdb_rate=8.40 AND meta_rate=98 AND
 budget=87 AND title="some text" AND revenue=85785 AND
 popularity=700 AND title='is the same in all rows' LIMIT 20 OFFSET 800000;

我在网上搜索并找到了如下所示的更好解决方案

我从here 中找到的

解决方案1：

#THIS QUERY EXECUTE FOR LESS THAN 1 seconds.
SELECT * FROM (SELECT id from movies  m LIMIT 20 OFFSET 800000)AS t1 INNER JOIN movies on t1.id=movies.id;

但是当我将解决方案1与过滤器一起使用时，它会变慢（我不知道为什么）

  #THIS QUERY EXECUTE AFTER 8 OR 15 seconds.
  SELECT * FROM (SELECT id FROM movies WHERE
     rotten_rate=78 AND imdb_rate=8.40 AND meta_rate=98 AND
     budget=87 AND title="some text" AND revenue=85785 AND
     popularity=700 AND title='is the same in all rows' LIMIT 20 OFFSET 800000)AS t1
     INNER JOIN movies on t1.id=movies.id

选项2：

（用于分页的主要搜索者方法）

我从here中发现，我应该说这对我来说是个好习惯 因为此方法仅对无限滚动或 分页之前和之后。您根本无法跳至特定 页。在第1页上说您，然后您要转到第800000页。 这种方法根本不好，因为您需要最后一个 页面799999，但您在页面上说4。

我大量搜索了一种针对特定页面执行分页的解决方案 页面从任何页面跳转到任何其他页面。但是我发现了这些 两种方法。有谁能帮助我？我希望有人为 MySQL社区或开发团队可以提供帮助，因为我知道 这不仅仅是我的问题。 谢谢我所有的朋友

解决方法

许多查询在查询引擎知道如何向您提供第一页的结果（以及要返回多少行）后立即“快速运行”。

在您的情况下，您可能会强迫SQL引擎实际分页浏览成千上万的结果行，以获得所需的切片。这不仅需要花费很长时间，而且给SQL Server本身带来了沉重负担-使其无法快速响应其他请求。

我认为您需要从根本上重新考虑您的方法，以使您的SQL结果集永远不会近那么大。您需要在SQL WHERE子句本身中找到一种“分页”的方法。