我想问一个关于如何使用 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 多分钟。
其他注意事项
- 由于插入特性,时间戳可能会重复。
- 定期插入必须与选择共存。
- 不对表执行任何更新或删除操作。
对“每个传感器一张表”方法的假设
- 每个传感器的表格会小得多,因此访问速度会更快。
- 将仅在每个传感器的一张表上执行选择。
- 选择来自不同传感器的混合数据不是时间紧迫的。
2015 年 2 月 2 日更新
我们为每一年的数据创建了一个新表,我们也每天对其进行分区。每个表有大约 2.5 亿行和 365 个分区。使用的新索引如 Ollie 所建议的那样(sensor_id、date、type_id、value),但查询仍然需要 30 秒到 2 分钟。我们不使用第一个查询(每日摘要),只使用第二个(垂直到水平 View )。
为了能够对表进行分区,必须删除主索引。
我们是否遗漏了什么?有没有办法提高性能?
非常感谢!
最佳答案
根据问题的变化进行编辑
尊重每个传感器一张表确实是一个非常糟糕的主意。有几个原因:
- 普通操作系统上的 MySQL 服务器很难处理数千张表。大多数操作系统无法同时处理那么多文件访问。
- 每次添加(或删除)传感器时都必须创建表格。
- 涉及来自多个传感器的数据的查询将会缓慢而复杂。
我之前版本的这个答案建议按时间戳进行范围分区。但这不适用于您的 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/