d--*_*--b 7 mysql sql performance
在mysql表中插入一些数据时出现性能问题.该表有一堆列,比如DATE,A,B,C,D,E,F,其中DATE,A,B,C,D,E是主键.每天,我在该表中插入70k行(具有不同的日期),此表现在包含1800万行.我用来插入行的方法只是发送70k INSERT查询.
我遇到的问题是查询开始比以前花费更多的时间.从几分钟到几个小时.我描述了插页,这是我得到的图表:
每个插入的速度(以秒为单位)与当天插入的数量:

一些奇怪的事实:
知道是什么原因引起的吗?
**编辑**索引中的列按以下顺序排列:
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,
Run Code Online (Sandbox Code Playgroud)
日期要么与今天相同,要么留空,双倍总是相同的数字(没有设计此表的线索)
简单的解释就是你有一个在单日范围内不增量的索引。非增量索引通常插入/更新速度较慢,因为它们比增量索引更经常需要重新平衡索引树,并且在更大程度上需要重新平衡索引树。
为了进一步解释这一点 - 假设以下模式:
a (int) | b (varchar)
Run Code Online (Sandbox Code Playgroud)
索引是(a, b)
现在我们插入:
1, 'foo'
2, 'bar'
3, 'baz'
Run Code Online (Sandbox Code Playgroud)
这将非常快,因为索引将附加到每个插入上。现在让我们尝试以下操作:
100, 'foo'
100, 'bar'
100, 'baz'
Run Code Online (Sandbox Code Playgroud)
这不会那么快,因为“bar”需要插入到“foo”之前,而“baz”需要插入到其他两个之间。这通常需要索引重写树以适应,并且这种“重新平衡”行动需要一些时间。重新平衡涉及的组件越大(在本例中为 a=100 的子集),所需的时间就越长。请注意,这种重新平衡活动只会更频繁、更广泛地发生,但不一定在每个插入上发生。这是因为树通常会在叶子内留下一些空间用于扩展。当叶子没有足够的空间时,它就知道是时候重新平衡了。
就您而言,由于您的索引主要基于当前日期,因此您会在一天的范围内不断重新平衡树。每天都会开始一个新的范围,并因此在当天的范围内开始重新平衡。最初,这仅涉及一些重新平衡,但随着当天现有条目范围的增加,这会增加。当你开始新的一天时,这个循环就会重新开始,这就是你所看到的结果。
主键发生这种情况可能会使情况变得更糟,因为可能需要移动整行数据来适应新条目,而不是移动一些索引指针。(最后一点假设 MyISAM 集群是在主键上执行的,这一点至今我还没有得到澄清,尽管轶事证据似乎确实支持这一点。例如,请参见此处和此处。)
| 归档时间: |
|
| 查看次数: |
1351 次 |
| 最近记录: |