简单 SELECT 查询很慢，大 table

Question

我有一个 table 具有以下结构

SHOW CREATE TABLE data_temperature;

CREATE TABLE `data_temperature` (
  `temperature_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `created` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `data_id` bigint(20) unsigned NOT NULL,
  `x_id` varchar(32) DEFAULT NULL,
  `x_sn` varchar(16) DEFAULT NULL,
  `x_unit` char(1) DEFAULT NULL,
  `x_value` decimal(6,2) DEFAULT NULL,
  PRIMARY KEY (`temperature_id`),
  KEY `created` (`created`),
  KEY `data_id` (`data_id`),
  KEY `x_value` (`x_value`)
) ENGINE=InnoDB AUTO_INCREMENT=6274618 DEFAULT CHARSET=latin1

我有一个从这里提取数据的基本查询，速度非常慢。所以我将查询分解为更简单的术语，发现这个非常简单的查询很慢（17.52 秒）：

SELECT data_temperature.x_value FROM data_temperature WHERE data_temperature.created BETWEEN '2015-02-02 18:28:42' AND '2015-03-04 18:28:42';

table 有 6,274,617 行。事实上，SELECT COUNT(*) FROM data_temperature 也需要 3.66 秒。

这个查询运行ning 所在的系统是我的开发系统，它是一个四核运行ning Ubuntu 14.04、4GB RAM 和一个固态 -状态驱动器。

这是关于运行这样的查询需要多长时间，还是我做错了什么？有没有更有效的方法来 return 数据？

Answer 1

想想输出有多少行。想想这些行占用了多少磁盘 space。想想磁盘有多慢运行。想想你将如何处理所有这些行。 17秒是合理的。

同样，由于其中的大部分因素，COUNT(*) 花费了 3.66 秒。

让我们深入挖掘。

InnoDB table 上的

SELECT COUNT(*) FROM tbl 将完全扫描其中一个索引，同时计算行数。该索引可能约为 100MB。它必须从磁盘中获取所有 100MB，除了可能已经缓存的所有内容。它必须查看 600 万行中的每一行，边走边数。总计：3.66 秒。

现在让我们看看另一个查询。它更复杂，因此更慢。

您有一个适合该 WHERE 子句的索引：INDEX(created)。那是在 BTree 中。首先，它会找到“2015-02-02 18:28:42”或之后的第一个条目。然后线性向前扫描，直到到达'2015-03-04 18:28:42'。这可能需要不到 3.66 秒。但是...

对于索引中的每个项目，它需要查找 value。它首先找到 PRIMARY KEY temperature_id，它在同一个 BTree 中，就在 created 旁边。使用temperature_id遍历另一棵BTree，即有PK和数据的BTree，找到对应的行。它在那里找到 value。在范围内重复 created。这些查找所需的块将是更多 MB 的数据。

可以使 SELECT 运行更快，但它只会帮助这个查询： INDEX(created, value)。这是一个 "covering" 索引。这意味着所有 SELECT 所需的列都在索引中找到。因此，它不需要进入另一个 BTree。这可能会导致 3.66 秒或更少的时间。

简单 SELECT 查询很慢，大 table

Simple SELECT query is slow with large table

mysql

mariadb

mysql-slow-query-log