gpt4 book ai didi

MySql MyISAM 插入缓慢

转载 作者:可可西里 更新时间:2023-11-01 06:38:09 25 4
gpt4 key购买 nike

我在 mysql 表中插入一些数据时遇到性能问题。该表有一堆列,假设 DATE,A,B,C,D,E,F 其中 DATE,A,B,C,D,E 是主键。每天,我在该表中插入 70k 行(日期不同),而该表现在包含 1800 万行。我用来插入行的方法只是发送 70k INSERT 查询。

我遇到的问题是查询开始比以前花费更多的时间。从几分钟到几个小时。我分析了插入内容,这是我得到的图表:

每次插入的速度(以秒为单位)与当天的插入次数: Speed of each insert (in sec) vs. Number of insert for that day

一些奇怪的事实:

  1. 大多数查询的执行时间不到 2 毫秒
  2. 慢速查询的速度随着该日期表中的行数线性增加
  3. 这种行为只发生在晚上,在数据库上发生了一堆进程之后。白天插入快,周末也快
  4. 整体速度不取决于数据库上还有什么在运行,事实上,发生这种情况时数据库上没有任何其他东西在运行
  5. 查询中没有任何东西可以解释一个查询快或不快,快的和慢的非常相似,一天到另一天不是同一组。
  6. 行为不会一天天改变。

知道是什么原因造成的吗?

** 编辑 ** 索引中的列按以下顺序排列:

DATE NOT NULL,
DATE NOT NULL,
VARCHAR (10) NOT NULL,
VARCHAR (45) NOT NULL,
VARCHAR (45) NOT NULL,
VARCHAR (3) NOT NULL,
VARCHAR (45) NOT NULL,
DOUBLE NOT NULL,
VARCHAR (10) NOT NULL,
VARCHAR (45) NOT NULL,
VARCHAR (45) NOT NULL,
VARCHAR (45) NOT NULL,

日期要么和今天一样,要么留空,双数总是相同的数字(不知道是谁设计了这个表)

最佳答案

简单的解释就是你有一个单日范围内非增量的索引。非增量索引通常插入/更新速度较慢,因为与增量索引相比,它们更经常需要重新平衡索引树,并且在更大程度上。

为了进一步解释这一点 - 假设以下架构:

a (int) | b (varchar)

索引是(a, b)

现在我们插入:

1, 'foo'
2, 'bar'
3, 'baz'

这将非常快,因为索引将附加到每个插入。现在让我们尝试以下操作:

100, 'foo'
100, 'bar'
100, 'baz'

这不会那么快,因为 'bar' 需要插入到 'foo' 之前,而 'baz' 需要插入到其他两个之间。这通常需要索引重写树来适应,而这“再平衡”行动需要一些时间。重新平衡中涉及的组件越大(在本例中为 a=100 的子集),花费的时间就越多。请注意,此重新平衡事件只会更频繁地更广泛地发生,但不一定在每次插入时发生。这是因为树通常会在叶子中留出一些空间用于扩展。当叶子用完空间时,它知道是时候重新平衡了。

在您的情况下,由于您的索引主要基于当前日期,因此您不断地在一天的范围内重新平衡您的树。每一天都开始一个新的范围,因此在当天的范围内开始重新平衡。最初这只涉及一些重新平衡,但随着当天现有条目范围的增加,这会增加。当您开始新的一天时,循环会重新开始,这就是您所看到的结果。

这发生在主键上可能会使事情变得更糟,因为不是移动一些索引指针,而是可能需要移动整行数据以容纳新条目。 (最后一点假设 MyISAM 集群是在主键上执行的,这一点我今天还没有得到澄清,尽管轶事证据似乎确实支持这一点。例如,参见 herehere 。 )

关于MySql MyISAM 插入缓慢,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/18857834/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com