我想问一个关于如何使用 innodb 引擎提高大 MySQL 表的性能的问题:

我的数据库中目前有一个表，其中包含大约 2 亿行。该表定期存储不同传感器收集的数据。表结构如下:

CREATE TABLE sns_value (
    value_id int(11) NOT NULL AUTO_INCREMENT,
    sensor_id int(11) NOT NULL,
    type_id int(11) NOT NULL,
    date timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
    value int(11) NOT NULL,
    PRIMARY KEY (value_id),
    KEY idx_sensor id (sensor_id),
    KEY idx_date (date),
    KEY idx_type_id (type_id) );

起初，我想在几个月内对表进行分区，但由于不断添加新传感器，它会在大约一个月内达到当前大小。

我想出的另一个解决方案是通过传感器对表格进行分区。然而，由于 MySQL 的 1024 个分区的限制，这不是一个选项。

我认为正确的解决方案是为每个传感器使用具有相同结构的表格:

sns_value_XXXXX

这样，每年将有 1000 多个表，估计大小为 3000 万行。同时，可以按月对这些表进行分区，以便最快地访问数据。

这个解决方案会导致什么问题？有没有更规范化的解决方案？

编辑附加信息

我认为该表相对于我的服务器来说很大:

• 云端 2 个 CPU 和 8GB 内存
• LAMP(CentOS 6.5 和 MySQL 5.1.73)

每个传感器可能有不止一种变量类型(CO、CO2 等)。

我主要有两个慢查询:

1) 每个传感器和类型(平均、最大、最小)的每日摘要:

SELECT round(avg(value)) as mean, min(value) as min, max(value) as max, type_id
FROM sns_value
WHERE sensor_id=1 AND date BETWEEN '2014-10-29 00:00:00' AND '2014-10-29 12:00:00'
GROUP BY type_id limit 2000;

这需要超过 5 分钟。

2) 垂直到水平 View 和导出:

SELECT sns_value.date AS date,
sum((sns_value.value * (1 - abs(sign((sns_value.type_id - 101)))))) AS one,
sum((sns_value.value * (1 - abs(sign((sns_value.type_id - 141)))))) AS two,
sum((sns_value.value * (1 - abs(sign((sns_value.type_id - 151)))))) AS three
FROM sns_value
WHERE sns_value.sensor_id=1 AND sns_value.date BETWEEN '2014-10-28 12:28:29' AND '2014-10-29     12:28:29'
GROUP BY sns_value.sensor_id,sns_value.date LIMIT 4500;

这也需要 5 多分钟。

其他注意事项

1. 由于插入特性，时间戳可能会重复。
2. 定期插入必须与选择共存。
3. 不对表执行任何更新或删除操作。

对“每个传感器一张表”方法的假设

1. 每个传感器的表格会小得多，因此访问速度会更快。
2. 将仅在每个传感器的一张表上执行选择。
3. 选择来自不同传感器的混合数据不是时间紧迫的。

2015 年 2 月 2 日更新

我们为每一年的数据创建了一个新表，我们也每天对其进行分区。每个表有大约 2.5 亿行和 365 个分区。使用的新索引如 Ollie 所建议的那样(sensor_id、date、type_id、value)，但查询仍然需要 30 秒到 2 分钟。我们不使用第一个查询(每日摘要)，只使用第二个(垂直到水平 View )。

为了能够对表进行分区，必须删除主索引。

我们是否遗漏了什么？有没有办法提高性能？

非常感谢!

最佳答案

根据问题的变化进行编辑

尊重每个传感器一张表确实是一个非常糟糕的主意。有几个原因:

1. 普通操作系统上的 MySQL 服务器很难处理数千张表。大多数操作系统无法同时处理那么多文件访问。
2. 每次添加(或删除)传感器时都必须创建表格。
3. 涉及来自多个传感器的数据的查询将会缓慢而复杂。

我之前版本的这个答案建议按时间戳进行范围分区。但这不适用于您的 value_id 主键。但是，根据您显示的查询和正确的表索引，可能不需要分区。

(如果可以，请避免使用列名 date:它是一个保留字，您在编写查询时会遇到很多麻烦。相反，我建议您使用 ts，这意味着时间戳。)

注意:int(11) 值对于您的value_id 列而言不够大。您将用完所有 ID。对该列使用 bigint(20)。

您提到了两个查询。使用适当的复合索引，这两个查询都可以变得非常高效，即使您将所有值保存在一个表中也是如此。这是第一个。

SELECT round(avg(value)) as mean, min(value) as min, max(value) as max,
       type_id
  FROM sns_value
 WHERE sensor_id=1
  AND date BETWEEN '2014-10-29 00:00:00' AND '2014-10-29 12:00:00'
GROUP BY type_id limit 2000;

对于此查询，您首先使用常量查找 sensor_id，然后查找一系列 date 值，然后聚合type_id。最后，您要提取 value 列。因此，所谓的compound covering index (sensor_id, date, type_id, value) 将能够通过索引扫描直接满足您的查询。这对您来说应该非常快——即使是一张大 table ，也肯定快于 5 分钟。

在您的第二个查询中，将使用类似的索引策略。

SELECT sns_value.date AS date,
       sum((sns_value.value * (1 - abs(sign((sns_value.type_id - 101)))))) AS one,
       sum((sns_value.value * (1 - abs(sign((sns_value.type_id - 141)))))) AS two,
       sum((sns_value.value * (1 - abs(sign((sns_value.type_id - 151)))))) AS three
  FROM sns_value
 WHERE sns_value.sensor_id=1
   AND sns_value.date BETWEEN '2014-10-28 12:28:29' AND '2014-10-29 12:28:29'
 GROUP BY sns_value.sensor_id,sns_value.date
 LIMIT 4500;

同样，您从 sensor_id 的常量值开始，然后使用 date 范围。然后提取 type_id 和 value。这意味着我提到的相同的四列索引应该适合您。

CREATE TABLE sns_value (
    value_id  bigint(20) NOT NULL AUTO_INCREMENT,
    sensor_id int(11) NOT NULL,
    type_id   int(11) NOT NULL,
    ts        timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
    value int(11) NOT NULL,
  PRIMARY KEY        (value_id),
  INDEX    query_opt (sensor_id, ts, type_id, value)
);

关于mysql - 提高大型 MySQL 表的性能，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/26615144/