14

我想我对此有一个基本的了解，但我希望有人能给我更多的细节，因为我有兴趣了解更多关于数据库性能的信息。

假设我有一个非常大的数据库，有数百万个条目，该数据库支持许多连接。由于数据太多，对数据库进行简单查询会很慢。我试图准确了解给定连接上的查询何时开始对在其他连接上运行的查询的性能产生直接影响。

如果一个连接锁定了某些元素，我知道这将阻止运行需要这些元素的其他连接的查询。例如做：

SELECT FOR UPDATE

将锁定您选择的内容。

当您执行以下简单操作时会发生什么：

SELECT COUNT(*) FROM myTable

假设我们有一个包含十亿行的表，因此运行计数需要一些时间（在 innodb 上运行）。它会影响在其他连接上运行的查询吗？

如果您使用 SELECT 和 JOIN 选择大量数据怎么办，例如：

SELECT * FROM myTable1 JOIN myTable2 ON myTable1.id = myTable2.id;

对其他查询有连接锁吗？

我发现很难知道哪些查询会对在其他连接上运行的查询的性能产生直接影响。

谢谢

4

3 回答 3

5

有不同的角度：

  • 行锁定：如果你调整你的架构，这不应该发生，所以你应该忘记它
  • 实际性能问题和瓶颈。在我们的例子中，附带影响。

关于这第二点，问题主要分为3个方面：

  • 磁盘读取
  • 内存使用（缓冲区）
  • CPU使用率。

关于磁盘读取：您将检索的数据（以字节为单位）越多，硬盘驱动器就越忙，并且会减慢使用它的任何其他活动。减小选定行的大小以避免磁盘开销。

关于内存使用：mysql 管理一个内部缓冲区，在某些情况下可能会卡住。我对此知之甚少，无法给你一个正确的答案，但我知道这绝对是你应该关注的事情。

关于cpu使用：基本上cpu会忙的时候

  • 必须计算（连接，准备语句，算术......）
  • 必须做所有外围的事情：例如将字节从磁盘移动到内存。优化查询以减少 CPU 开销。（听起来很傻，但是，无论如何，它总是成为问题......）

那么，现在什么时候知道什么时候会产生附带效应呢？通过分析您的硬件... 如何分析？

  • 绝对分析：使用SHOW INNODB STATUS或SHOW PROFILE获取有关主 mysql 硬盘、cpu 和内存监视的有用信息。
  • 相对分析：使用您最喜欢的操作系统分析器。比如在windows xp下，你可以使用mysql进程的great perfmon.exeand watch for PRIVATE BYTESand VIRTUAL BYTES。我说的是相对的，因为毕竟如果查询在您的计算机上很耗时，那么它可能不在 NASA 系统上......

希望它有帮助，问候。

于 2012-07-01T19:35:31.047 回答
3

读取查询仅受其他查询的隔离级别影响。他们自己从来没有挡住桌子。

隔离级别是指定的事务安全模式。如果另一个使用锁定的查询不允许脏读，则您的读取将被保留，直到另一个查询完成写入或解锁。

MVCC是一种允许数据库在需要更新或删除数据时创建新版本数据的机制。这意味着当您开始读取当前版本的数据时，它的数据不会被未来的更新/删除所污染。

当您开始写入当前数据时，尽管数据当前正在被另一个进程读取，您实际上是在其他地方写入新内容并将它们标记为最新版本。这最终意味着写入过程没有阻塞（至少不是因为读取过程）。

于 2012-07-01T19:35:08.507 回答
3

这是一个非常笼统的问题，因此很难给出准确的答案。

您可以将数据库视为共享资源池；特别是因为你的数据库运行的底层硬件有物理限制。大多数情况下，您看到诸如选择查询之类的东西会对其他查询造成性能影响的原因是，它们都在竞争使用诸如磁盘 IO 或 RAM 访问或 CPU 时间之类的底层物理资源，并且没有足够的时间来解决.

因此，您将看到的实际结果在很大程度上取决于数据库的物理硬件和配置设置。

例如，在您选择的示例中，变量可能是：查询需要的数据是否已经在 RAM 中？它可以通过索引有效地查找行吗？如果它必须做 IO，有多少其他查询要求从磁盘读取数据？您是否使用二级索引并且必须进行多次读取？数据库是否在进行预读以缓冲其他页面？查询是否导致顺序或随机 io？是否有任何更新锁定了数据？物理硬件能支持多少读IO？

您必须回答当前正在执行的所有查询的所有这些问题，以了解它们是否会影响其他查询的性能。

这就是 DBA 存在的原因。繁忙的数据库是一个复杂的系统，它是关于大量不同操作的交互，所有这些操作都有数以千计的可能变量影响它们。

所以你通常做的是优化你可以控制的东西以及你知道如何（硬件、mysql配置、模式和索引）然后在系统运行时开始测量系统以了解实际发生的情况。

因此，在您的情况下，我会说专注于简单地单独优化您的查询会更有帮助。他们执行得越快，他们可能使用的资源就越少，他们对其他人的影响就越小。然后你学会分析系统。只看一件很慢的东西，然后问“为什么这么慢？” 然后修复它。这就是优化过程。

但是，在第一种情况下，您使用 SELECT ... FOR UPDATE 显式锁可能并且将会是很大的性能问题。小心那些。

于 2012-07-01T19:46:59.353 回答