【问题标题】:Why mariadb partitioning doesn't give me better performance?为什么 mariadb 分区不能给我更好的性能?
【发布时间】:2015-10-27 06:38:01
【问题描述】:

问候。

让我先展示一下我的表格方案:

CREATE TABLE `log_table` (
`rid` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`dataId` int(10) unsigned NOT NULL DEFAULT '0',
`memberId` int(10) unsigned NOT NULL DEFAULT '0',
`clientId` int(10) unsigned NOT NULL DEFAULT '0',
`qty` int(11) NOT NULL DEFAULT '0',
`timestamp` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
`typeA` tinyint(2) DEFAULT NULL,
`typeB` int(11) DEFAULT '0',
PRIMARY KEY (`rid`,`timestamp`),
KEY `idx_report1` (`timestamp`,`memberId`,`dataId`),
KEY `idx_report2` (`memberId`,`timestamp`),
KEY `idx_report3` (`dataId`,`timestamp`,`rid`),
KEY `idx_report4` (`timestamp`,`typeB`,`typeA`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
PARTITION BY RANGE (year(`timestamp`))
(PARTITION p2014 VALUES LESS THAN (2015),
 PARTITION p2015 VALUES LESS THAN (2016)
);

我使用的是 MariaDB 5.5,这个表包含 2500 万条记录,所以我决定在表中进行分区,以防止在不久的将来可能出现性能问题。 您可能会看到它是时间序列、日志数据和 4 个视图。例如,其中一个视图使用以下查询:

select typeB, typeA, count(*) as number from log_table where timestamp between '2015-1-1' and '2015-2-1' group by typeB, typeA;

AFAIK,此查询仅通过分区修剪从 p2015 加载数据。但是我看到原始表和分区版本在查询执行时间上没有太大区别。 (平均 1.94 秒对比 1.95 秒)

嗯,我认为这可能会受到每个分区中的行数的影响。那么小一点的分区呢? to_days()?

PARTITION BY RANGE (to_days(`timestamp`))
(
...
PARTITION p_2015_01 VALUES LESS THAN (to_days('2015-2-1')),
PARTITION p_2015_02 VALUES LESS THAN (to_days('2015-3-1'))
...
)

嗯,没有效果。你能告诉我我缺少什么吗?


编辑:对于我在查询中的错误感到抱歉。顺便说一句,EXPLAIN PARTITION 对我没有帮助。

解释两个表的结果是:

// original
+------+-------------+-----------+-------+-------------------------+-------------+---------+------+---------+-----------------------------------------------------------+
| id   | select_type | table     | type  | possible_keys           | key         | key_len | ref  | rows    | Extra                                                     |
+------+-------------+-----------+-------+-------------------------+-------------+---------+------+---------+-----------------------------------------------------------+
|    1 | SIMPLE      | org_table | range | idx_report1,idx_report4 | idx_report4 | 8       | NULL | 8828000 | Using where; Using index; Using temporary; Using filesort |
+------+-------------+-----------+-------+-------------------------+-------------+---------+------+---------+-----------------------------------------------------------+


//partition
+------+-------------+-----------+-------+-------------------------+-------------+---------+------+---------+-----------------------------------------------------------+
| id   | select_type | table     | type  | possible_keys           | key         | key_len | ref  | rows    | Extra                                                     |
+------+-------------+-----------+-------+-------------------------+-------------+---------+------+---------+-----------------------------------------------------------+
|    1 | SIMPLE      | log_table | range | idx_report1,idx_report4 | idx_report4 | 8       | NULL | 7902646 | Using where; Using index; Using temporary; Using filesort |
+------+-------------+-----------+-------+-------------------------+-------------+---------+------+---------+-----------------------------------------------------------+

【问题讨论】:

  • 您对查询的解释计划是什么样的?顺便说一句,好帖子 +1 上的荣誉
  • 您的表中没有记录日期字段。那么,您能否更新查询或创建表以相互匹配?请发布结果以解释这两个查询。我怀疑 recdate 字段已编入索引,而且记录按日期分组存储在日志表中,因此执行时间差异不大。

标签: mysql mariadb


【解决方案1】:

PARTITIONing 对性能的帮助几乎没有用户认为的那么频繁。

KEY `idx_report4` (`timestamp`,`typeB`,`typeA`)

对于您提供的SELECT,不进行分区是最佳选择。 PARTITIONing 不会加快速度。

由于BETWEEN 是“包容性”where timestamp between '2015-1-1' and '2015-2-1' 实际上会命中两个分区。使用EXPLAIN PARTITIONS SELECT ... 来查看。

BY RANGE (TO_DAYS(...)) 可能比BY RANGE (YEAR(...)) 更好,但对于给定的查询仍然没有用。

这是我对PARTITIONing 有助于提高性能的 4 个用例的讨论:http://mysql.rjweb.org/doc.php/partitionmaint

如果这种类型的查询很重要,请考虑将“汇总表”作为一种大大加快应用程序速度的方法:http://mysql.rjweb.org/doc.php/datawarehousehttp://mysql.rjweb.org/doc.php/summarytables

【讨论】:

  • 感谢您的回答。
猜你喜欢
  • 1970-01-01
  • 2016-01-16
  • 1970-01-01
  • 2010-09-11
  • 2017-07-20
  • 2012-11-10
  • 1970-01-01
  • 2019-04-15
相关资源
最近更新 更多