我有一个应用程序与数据库有一些问题:当它试图打开与数据库的连接(或执行查询，这还不清楚)时突然卡住。没有错误信息。我怀疑有一些查询阻止了其他查询，我正试图弄清楚那是什么。 我用过

SET profiling=1;

但是当我执行时:

show profiles;

我只得到我自己执行的查询，而不是应用程序查询(应用程序和我使用的是同一个用户)。

打电话

 SHOW FULL PROCESSLIST;

返回一个包含所有进程的表。

+-----+----------+---------------------+--------+---------+------+-------+-----------------------+
| Id  | User     | Host                | db     | Command | Time | State | Info                  |
+-----+----------+---------------------+--------+---------+------+-------+-----------------------+
|   8 | user     | <HOST>              | DBs    | Sleep   |    3 |       | NULL                  |
| 722 | user     | <HOST>              | DBs    | Sleep   | 8205 |       | NULL                  |
| 726 | user     | <HOST>              | DBs    | Sleep   | 8212 |       | NULL                  |
| 727 | user     | <HOST>              | DBs    | Sleep   | 8205 |       | NULL                  |
| 728 | user     | <HOST>              | DBs    | Sleep   | 8205 |       | NULL                  |
| 730 | user     | <HOST>              | DBs    | Sleep   | 7172 |       | NULL                  |
| 732 | user     | <HOST>              | DBs    | Sleep   | 8095 |       | NULL                  |
| 733 | user     | <HOST>              | DBs    | Sleep   | 8055 |       | NULL                  |
| 735 | user     | <HOST>              | DBs    | Sleep   | 8075 |       | NULL                  |
| 736 | user     | <HOST>              | DBs    | Sleep   | 8075 |       | NULL                  |
| 737 | user     | <HOST>              | DBs    | Sleep   | 8035 |       | NULL                  |
| 738 | user     | <HOST>              | DBs    | Sleep   | 8015 |       | NULL                  |
| 740 | user     | <HOST>              | DBs    | Sleep   | 7995 |       | NULL                  |
| 741 | user     | <HOST>              | DBs    | Sleep   | 7975 |       | NULL                  |
| 742 | user     | <HOST>              | DBs    | Sleep   | 7955 |       | NULL                  |
| 774 | user     | <HOST>              | DBs    | Sleep   | 5772 |       | NULL                  |
| 779 | user     | <HOST>              | DBs    | Sleep   | 6068 |       | NULL                  |
| 806 | user     | <HOST>              | DBs    | Query   |    0 | init  | SHOW FULL PROCESSLIST |
+-----+----------+---------------------+--------+---------+------+-------+-----------------------+

打电话

show engine innodb status

返回很多交易，一些活跃的，一些还没有开始。但没有关于锁定查询的信息。

这个查询，据说会给我有关被阻止查询的信息，返回一个空集:

SELECT r.trx_id waiting_trx_id, r.trx_mysql_thread_id waiting_thread, r.trx_query waiting_query, b.trx_id blocking_trx_id,  b.trx_mysql_thread_id blocking_thread, b.trx_query blocking_query FROM       information_schema.innodb_lock_waits w INNER JOIN information_schema.innodb_trx b  ON   b.trx_id = w.blocking_trx_id INNER JOIN information_schema.innodb_trx r  ON   r.trx_id = w.requesting_trx_id;

有了所有这些信息，我可以保证没有死锁吗？

你能猜猜会发生什么吗？这样我就可以研究它了？

有什么方法可以获得有关流程的更多信息？

我是数据库管理和 MySQL 的新手。

谢谢

最佳答案

锁等待延迟

锁定等待可能就是您的意思。您可以通过启用慢查询日志、收集一堆日志然后查看它来监控锁等待。这是一个例子:

# Time: 140605 15:00:06
# User@Host: appuser[appuser] @  [127.0.0.1]  Id:    29
# Schema:   Last_errno: 0  Killed: 0
# Query_time: 0.011732  Lock_time: 0.000161  Rows_sent: 214  Rows_examined: 214  Rows_affected: 0
SET timestamp=1402005606;
SELECT ...blah blah blah...

您可以看到上面的字段 Lock_time，它表明查询在开始执行之前等待锁定 161 微秒。然后执行时间不到 12 毫秒(由 Query_time 显示)。

Lock_time 非常小是正常的，通常它甚至超出刻度，所以它只显示为 0.000000。如果它进入数百毫秒或更长时间，那是不寻常的。如果它进入整秒，你就有麻烦了。

请注意，慢查询日志条目不会写入日志，除非 Query_time 超过您的配置变量 long_query_time -- 即使 Lock_time 很大。有关此的更多讨论，请参阅 http://www.mysqlperformanceblog.com/2012/11/22/get-me-some-query-logs/

连接延迟

您还提到，在您运行任何查询之前，获取连接可能会导致延迟。您需要追踪是否是这种情况。在任何应用程序语言中都应该很容易读取连接数据库前后的时间，并比较它们需要多长时间。一些框架甚至为每个查询提供这种类型的应用程序级分析(或者您可以自己做)。

例如，连接延迟的一个常见原因是 MySQL 服务器正在执行反向 DNS 查找以将传入套接字的 IP 地址转换为主机名。它这样做是为了可以在授权表中查找主机名，以确定 user@host 拥有哪些特权。但是，如果您的 DNS 服务器速度慢或过载，这可能会很慢。令人惊讶的是，它会超过几分之一秒，但这是可能的。

您可以通过设置配置变量 skip_name_resolve 来加快速度。这意味着您不能根据主机名向用户授予权限，您必须仅通过 IP 地址来识别用户。现实世界中的大多数生产 MySQL 实例都设置了 skip_name_resolve。

也可能有其他导致连接缓慢的原因，但首先进行一些应用程序分析，最终确定是连接缓慢还是查询造成的。

P.S.:很多人在说“锁等待”时会说“死锁”。死锁是指两个事务因等待对方的锁而无法继续进行。死锁不会导致延迟，因为 InnoDB 会立即注意到循环依赖并终止其中一个事务。您可以在标题为“LATEST DEADLOCK”的部分中的 SHOW ENGINE INNODB STATUS 中查看您是否遇到了死锁。

关于mysql - 如何检测 MySQL 中的死锁？什么会导致我的应用程序在建立连接时挂起？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/24167745/