mysql中inster是什么含义,在MySQL表中,INSERT性能始终如一的可能原因是什么？

我有一个在VM上运行的Java程序,它通过单个连接顺序地将单行INSERT队列提供给同一VM上的MySQL服务器.队列执行不是人为限制的 – 一旦查询完成执行,下一个执行就会立即执行.队列也永远不会是空的.

数据将插入到四个不同的MyISAM表中.其中两个具有UNIQUE列,另外两个具有跨两列的UNIQUE CONSTRAINT.程序生成的大多数数据已经存在于db中,但是不是检查重复项,程序只会将数据抛出到db并忽略重复的错误.

现在我用java程序记录每个查询的执行时间.显然执行时间略有偏差,因为它是由Java而不是MySQL定时的,但我能够通过将较长的时间帧除以该时间帧中执行的查询总数来验证平均执行时间的准确性.所以我假设我的Java应用程序的时间是准确的.

在实际问题上：我观察到每个INSERT的平均时间每隔几小时或几分钟就相当一致(但不是逐渐地)上升和下降两倍.这种增加或减少在不同类型的INSERTS中是一致的,因此它应该独立于所使用的表.

MySQL正在稳定地使用VM的22％RAM,Java使用大约7％.

VM有四个CPU核心.两个从未使用过,Java使用10-30％的一个而MySQL使用30-60％(从不多)的另一个.

VM上没有其他任何东西在运行.

如果我启动第二个应用程序,为另一组表排队INSERT,每个内核的CPU使用率上升50-100％,平均执行时间会有所增加(我不确定这是因为执行时间是这样的反正不一致).

一旦平均执行时间达到最小值约20小时,通常是每天几小时的最小值或最大值,然后在一天中的大部分时间内上下移动一点.

我对这种看似随机性能波动的可能原因一无所知,所以我们非常感谢任何想法.

编辑：我应该补充一点,当我在InnoDB表中进行100行到1000行的批量INSERT时,我遇到了同样的现象.

解决方法:

简单的答案是：无法猜出争用的来源是什么.

更详细：MySQL 5.6可以检测查询执行时间的细分,以便您可以查看性能是否等待IO,锁等等.

诊断功能称为performance_schema.开始使用它的最简单方法是下载MySQL Workbench 6.1并选择“Performance Reports”(在Performance下).

标签：java,performance,mysql,insert

来源： https://codeday.me/bug/20190806/1604278.html