一个走主键的查询很慢的问题

refineoracle

1.统计下这些运行缓慢sql的 Time、ip、Id，会不会集中在一个特别的时间，或者来自相同的应用。
2.手工 IGNORE INDEX查询一下，看看所用时间大概是多少。

millerrch

jinguanding 发表于 2013-8-20 11:14
这个lock 的意思，表示其锁记录的 或锁表的时长，不是其等待的时长～～～ 越是2个值差别大，越说明有锁等 ...

你的意思是说这个Lock值是当前分析的这个sql语句对涉及到的表锁住的时间，而不是等待被锁表的时间，是吧

waityou81

jinguanding 发表于 2013-8-20 11:14
这个lock 的意思，表示其锁记录的 或锁表的时长，不是其等待的时长～～～ 越是2个值差别大，越说明有锁等 ...

你的意思和我理解的意思不同啊。我的理解是这个Lock_time是当前语句等待别的session释放锁的时间而不是当前语句锁记录或表的时间。按照你的意思，如果一个select的query time很长而lock_time很短，这代表这个select会锁住表或记录？

waityou81

jinguanding 发表于 2013-8-20 11:14
这个lock 的意思，表示其锁记录的 或锁表的时长，不是其等待的时长～～～ 越是2个值差别大，越说明有锁等 ...

我做了一个简单的测试。
session1:
MariaDB [test]> select * from ee;
+------+
| ee   |
+------+
|    8 |
|    8 |
+------+
2 rows in set (0.00 sec)

MariaDB [test]> show create table ee;
+-------+--------------------------------------------------------------------------------------+
| Table | Create Table                                                                         |
+-------+--------------------------------------------------------------------------------------+
| ee    | CREATE TABLE `ee` (
  `ee` int(11) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 |
+-------+--------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

MariaDB [test]> begin;
Query OK, 0 rows affected (0.00 sec)

MariaDB [test]> update ee set ee=10;
Query OK, 2 rows affected (0.00 sec)
Rows matched: 2  Changed: 2  Warnings: 0

session2:
MariaDB [test]> update ee set ee=11;
Query OK, 2 rows affected (5.20 sec)
Rows matched: 2  Changed: 2  Warnings: 0

这个时候session 2会被阻塞。等待大概5s后提交session1,然后session2的语句会成功执行，同时slow log也会记录session2这个语句：
# User@Host: root[root] @ localhost []
# Thread_id: 60  Schema: test  QC_hit: No
# Query_time: 5.192962  Lock_time: 5.183352  Rows_sent: 0  Rows_examined: 2
SET timestamp=1377022063;
update ee set ee=11;


可以看到Lock_time: 5.183352，表示是它等待其他session释放锁的等待时间，而不是当前session锁记录的时间

lzd_7993

sql语句本身没有问题就是有锁表情况。

lzd_7993

还是可以lock锁的问题或某个事件等待造成的。

jan_1985

提议看一下查询发生时系统资源的使用情况vmstat  , top。并且慢查询发生时用profiling工具抓一下查询的统计信息。
有可能是IO或者CPU繁忙的原因。