MYSQL InnoDB :why performance after increasing the buffer pool size isn't even close to the MEMORY engine?

Question

我有一个包含单个表的数据库。 table 的大小是3.5 Gs。

我正在使用三种不同的配置对表进行只读查询:
1- Innodb 默认缓冲池大小。
2- Innodb 缓冲池大小 = 6G。
3-内存引擎。

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

如果增加缓冲池大小将使数据库像“内存中”数据库......为什么内存引擎和缓冲池之间存在巨大差距，有足够大的空间来容纳表。

笔记:
1-我正在一台专用机器上进行实验。

2- 当使用 6G 的缓冲池时...不会发生交换，因此该表可以轻松地容纳在内存中...无需交换。

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-我正在运行的查询，(即)tpch 的查询 6

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;

Answer 1

• 有没有索引吗？或者表中有INDEX(l_shipdate)和INDEX(l_discount)和INDEX(l_quantity)以便优化器可以在其中进行选择？
• 请提供EXPLAIN SELECT ...对于 InnoDB 和 Memory 版本。
• 您是否运行一个连接来重复执行该查询？还是很多？或者太多以至于你已经耗尽了资源？

INDEX(l_shipdate, l_discount, l_quantity)没有好处，因为优化器无法真正处理多个“范围”，并且 WHERE 的每个部分是一个“范围”。

令我惊讶的是，速度比超过了3:1。内存必须进行表扫描，测试每一行。 InnoDB，对于 3 个索引，我建议可能使用一个索引。这取决于数据的分布。说到这里，该日期范围内有多少行？在那个折扣范围内？在那个数量范围内？

每个计时你运行了两次吗？第一次会有 I/O，但是“预热缓存”；第二个(大概)没有 I/O。