MySQL多索引条件变慢了吗？

Question

我有一个这样定义的表：

article | CREATE TABLE `article` (
  `id` varchar(64) NOT NULL,
  `type` varchar(16) DEFAULT NULL,
  `title` varchar(1024) DEFAULT NULL,
  `source` varchar(64) DEFAULT NULL,
  `over` tinyint(1) DEFAULT NULL,
  `taken` tinyint(1) DEFAULT NULL,
  `released_at` varchar(32) DEFAULT NULL,
  `created_at` timestamp NULL DEFAULT NULL,
  `updated_at` timestamp NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_article_over` (`over`),
  KEY `idx_article_created_at` (`created_at`),
  KEY `idx_article_type` (`type`),
  KEY `idx_article_taken` (`taken`),
  KEY `idx_article_updated_at` (`updated_at`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 |

mysql> select count(1) from article;
+----------+
| count(1) |
+----------+
|   649773 |
+----------+
1 row in set (0.61 sec)

当我进行查询时：

SELECT * FROM `article` where taken=0  ORDER BY updated_at asc limit 10;

或

SELECT * FROM `article` where over=0  ORDER BY updated_at asc limit 10;

他们都很快。

然而，当我使用它时，它变得非常慢：

SELECT * FROM `article` where taken=0 and over=0  ORDER BY updated_at asc limit 10;

需要4.94s。

如果文章表增长到2000万行，则需要更长的时间。

下面是包含2000万行的解释：

mysql> explain SELECT * FROM `article` where taken=0 and processed=0  ORDER BY updated_at asc limit 10;
+----+-------------+-----------+------------+-------------+---------------------------------------------+---------------------------------------------+---------+------+---------+----------+-------------------------------------------------------------------------------------------+
| id | select_type | table     | partitions | type        | possible_keys                               | key                                         | key_len | ref  | rows    | filtered | Extra                                                                                     |
+----+-------------+-----------+------------+-------------+---------------------------------------------+---------------------------------------------+---------+------+---------+----------+-------------------------------------------------------------------------------------------+
|  1 | SIMPLE      | article   | NULL       | index_merge | idx_article_processed,idx_article_taken     | idx_article_processed,idx_article_taken     | 2,2     | NULL | 6234059 |   100.00 | Using intersect(idx_article_processed,idx_article_taken); Using where; Using filesort |
+----+-------------+-----------+------------+-------------+---------------------------------------------+---------------------------------------------+---------+------+---------+----------+-------------------------------------------------------------------------------------------+


mysql> SELECT * FROM `judgement` where taken=0 and processed=0  ORDER BY updated_at asc limit 10;
+--------------------------------------+----------+-----------+---------------------------------------------------------------------------
| id                                   | type     | title     | source|     processed | released_at | created_at       | updated_at  | taken |
+--------------------------------------+----------+-----------+---------------------------------------------------------------------------
10 rows in set (9 min 15.97 sec)

两个都有索引，为什么我把它们放在一起，查询变得更糟？由于索引更多，它不应该更快吗？

Answer 1

我不知道这个问题的确切答案“为什么当文章表增长到2000万行时，它会变慢”。

您的查询正在执行两个操作：

文件排序-使用intersect(，idx_article_taken)

• Using
• index_merge idx_article_processed

我只猜测表MySql中最多有2000万行可以在内存中执行这两个操作，但是超过这个限制，其中一个操作(或者可能两个操作)无法放入内存缓冲区，并且MySql必须使用磁盘上的文件，这要慢得多。

您可以增加内存缓冲区来推送一些MySql参数，也可以创建专门用于查询的索引：

对于此查询：

SELECT * FROM `article` where taken=0  ORDER BY updated_at asc limit 10;

创建此索引：

CREATE INDEX my_new_index ON article( taken, updated_at )

对于此查询：

SELECT * FROM `article` 
where taken=0 and over=0  
ORDER BY updated_at asc limit 10;

创建此索引：

CREATE INDEX my_new_index1 ON article( taken, over, updated_at )

在这些新索引的帮助下，文件排序和兆位操作都将被消除。

Answer 2

导航索引所涉及的工作比表扫描要快得多。是/否，如果存在均匀的拆分，索引可能几乎一文不值。

如果只有几个匹配的行，请考虑为这些相关行构建另一个表，然后重新连接，在处理这些行时将其删除。在其他dbs中，您将构建一个条件索引。

Answer 3

它“变慢了”，因为同时有两个taken=0 and over=0的行数不是很多。而且innodb_buffer_pool_size太小了。但是，要小心，该设置不应该太大而导致交换。您有多少RAM可用？