2017-09-14 30 views
0

我有一个包含单个表的数据库。桌子的大小是3.5 Gs。MYSQL InnoDB:为什么增加缓冲池大小之后的性能甚至不接近MEMORY引擎?

我在桌子上做一个只读的查询,使用三种不同的配置:
1- Innodb的默认缓冲池大小。
2- Innodb缓冲池大小= 6G。
3-内存引擎。

三种不同配置的运行时间:
1-默认缓冲池大小.... 15,53秒。
2-缓冲池大小= 6G ...... 13,60秒。
3-内存引擎.... 3,96秒。
....

如果增加缓冲池大小应当像“内存”数据库....数据库为什么会出现内存引擎和巨大足够的空间缓冲池之间的巨大差距包含表格。

备注:
1-我正在专用机器上做实验。

2-当使用具有6Gs的缓冲池时....不会发生交换,所以表格可以舒适地放在内存中......不需要交换。

3-我多次进行查询以确保“热数据”被加载到主内存中......并且我正在观看内存消耗......它在做完之后从500 MB变成了4G查询....缓冲池6G设置。

4-表使用该命令创建:

CREATE TABLE lineitem ( 
L_ORDERKEY INTEGER NOT NULL, 
L_PARTKEY  INTEGER NOT NULL, 
L_SUPPKEY  INTEGER NOT NULL, 
L_LINENUMBER INTEGER NOT NULL, 
L_QUANTITY DECIMAL(15,2) NOT NULL, 
L_EXTENDEDPRICE DECIMAL(15,2) NOT NULL, 
L_DISCOUNT DECIMAL(15,2) NOT NULL, 
L_TAX   DECIMAL(15,2) NOT NULL, 
L_RETURNFLAG CHAR(1) NOT NULL, 
L_LINESTATUS CHAR(1) NOT NULL, 
L_SHIPDATE DATE NOT NULL, 
L_COMMITDATE DATE NOT NULL, 
L_RECEIPTDATE DATE NOT NULL, 
L_SHIPINSTRUCT CHAR(25) NOT NULL, 
L_SHIPMODE  CHAR(10) NOT NULL, 
L_COMMENT VARCHAR(44) NOT NULL); 


5-我运行查询,(IE),所述TPCH

select 
sum(l_extendedprice * l_discount) as revenue 
from 
    tpch2.lineitem 
where 
    l_shipdate >= date '1994-01-01' 
    and l_shipdate < date '1994-01-01' + interval '1' year 
    and l_discount between 0.06 - 0.01 and 0.06 + 0.01 
    and l_quantity < 24; 
+0

您是否尝试添加像'ALTER TABLE lineitem ADD INDEX shipdate_discount_quantity(l_shipdate,l_discount,l_quantity)'索引;'使用** InnoDB **时?如果不是,你可以这样做,并报告测试时间结果? – codtex

+0

@codtex,非常感谢您的评论。不,我没有索引。
与建立索引:
默认缓冲池大小时间:15,65秒
缓冲池大小= 6G:13,32秒 –

+0

所以我看不出有或没有索引的区别...这很奇怪。也许你可以尝试在你的select语句中使用'EXPLAIN',无论如何,它似乎在试图帮助提高查询的速度,而不是回答实际问题“为什么内存引擎和缓冲池之间存在巨大差距有足够的空间来容纳表格?_“。我可以给出的其他建议是尝试使用[PARTITIONING](https://dev.mysql.com/doc/refman/5.7/en/partitioning.html),阅读[this](https://dev.mysql.com /doc/refman/5.7/en/partitioning-overview.html) – codtex

回答

0
  • 是查询6有没有索引?或者表格是否有INDEX(l_shipdate)INDEX(l_discount)INDEX(l_quantity),以便优化器可以从中挑选?
  • 请为InnoDB和Memory版本提供EXPLAIN SELECT ...
  • 您是否正在运行一个连接重复执行该查询?还是很多?还是那么多,你正在最大限度地利用资源?

INDEX(l_shipdate, l_discount, l_quantity)不是有益的,因为优化器不能真正处理一个以上的“范围”,并WHERE的每一部分是“范围”。

我很惊讶速度比超过3:1。内存将不得不做表扫描,测试每一行。 InnoDB,与我建议的3个指标可能使用索引。这取决于数据的分布。说到这一点,该日期有多少行?在这个折扣范围内?在这个数量范围内?

您是否每次运行两次?第一次将有I/O,但“预热高速缓存”;第二个(可能)没有I/O。