【问题标题】：Why sometime query take 3 second for complete job为什么有时查询需要 3 秒才能完成工作
【发布时间】：2013-03-29 05:03:44
【问题描述】：

应用程序是实时站点，需要每个查询的访问速度（选择、更新、插入）每次查询的低延迟必须小于 200 毫秒

嗯，平均每个查询有 98%。完成作业查询的时间少于 0.001-0.005 秒。

问题是有时每小时大约 5 次，它们可能需要 1s 并且可能是 5s，我不知道问题的真正原因

我发现减少问题的方法是将其从 INNODB 移到 MEMORY。

问题是为什么有时查询可能需要长达 5 秒的时间？

Example query in sometime query more than 1 secound

# Time: 130328 20:27:40
# User@Host: ferge572w[ferge572w] @ localhost []
# Query_time: 1.339712  Lock_time: 0.000026 Rows_sent: 0  Rows_examined: 1
SET timestamp=1364477260;
UPDATE log_product SET credit=credit+1 WHERE id_product='149721921' and id_user='2029275' LIMIT 1;

table index: id_product, id_user
No.row: 33,491   table size: 5Mb

# Time: 130329  7:25:37
# User@Host: ferge572w[ferge572w] @ localhost []
# Query_time: 1.439856  Lock_time: 0.000031 Rows_sent: 0  Rows_examined: 1
SET timestamp=1364516737;
UPDATE product SET lastuser='hello',picperson='1',lastid='2030505',country='thailand',price=price+0.01,time=DATE_ADD(time, INTERVAL 3 SECOND) WHERE id='349721227' LIMIT 1;

table index: id
No.row: 35   table size: 2.1Mb

我确保 EXPLAIN 优化查询和更新使用索引。还检查了表字段的数据类型及其长度，但仍然有问题

更新我发现问题的原因是系统高 IOwait 时。慢查询 heppen 立即。如何解决它

IO 等待高时查询慢。

从 iotop 命令显示

-- TID -- PRIO -- 用户 -- 磁盘读取 -- 磁盘写入 -- SWAPIN -- IO> -- 命令

-- 2311 -- be/4 -- mysql -- 0.00 B/s -- 0.00 B/s -- 0.00% -- 96.25% -- mysql~l.sock

-- 2311 -- be/4 -- mysql -- 0.00 B/s -- 0.00 B/s -- 0.00% -- 96.25% -- mysql~l.sock

-- 2311 -- be/4 -- mysql -- 0.00 B/s -- 0.00 B/s -- 0.00% -- 96.24% -- mysql~l.sock

高 IO 等待从下午 6:13:28 到下午 6:13:29（sar 命令）开始

--------------------- CPU -- %usr -- %nice -- %sys -- %iowait -- %steal

-- 下午 6:13:28 --- 全部 -- 2.53 -- 0.00 -- 2.02 -- 39.39 -- 0.00

-- 下午 6:13:29 --- 全部 -- 1.99 -- 0.00 -- 1.00 -- 49.25 -- 0.00

这段时间的查询速度很慢

时间：130329 18:13:29

用户@主机：wdwdwd[wdwdwd]@本地主机[]

Query_time: 2.007902 Lock_time: 0.000025 Rows_sent: 0 Rows_examined: 1 SET timestamp=1364555609;

UPDATE log_product SET credit=credit+1 WHERE id_product='349721228' and id_user='2021841' LIMIT 1;

【问题讨论】：

也许使用像 munin 这样的服务来随着时间的推移创建这些漂亮的图表，这样你就可以看到是否有基于时间的模式。 oierud.name/bliki/ImprovedMuninGraphsForMySQL.html
你有totutial来设置munin吗？ CentOS 6.4。谢谢
如果你可以重新出现这个问题，尝试使用配置文件dev.mysql.com/doc/refman/5.5/en/show-profile.html
我找到了原因，在上面更新了。

标签： php mysql

【解决方案1】：

可能有多种原因，您拥有（和检查）的数据越多，您就越能找到答案。

检查事项：

您是否使用共享主机，它们可能不可靠。
您检查过 mySQL 慢日志
您是否对查询进行了 mysql 解释？
当您的 SQL 查询太慢时，您是否收到大量请求，磁盘 IO 可能是个问题
您的表需要优化吗？
您的机器内存不足吗？

http://newrelic.com/ 在这些情况下会很有帮助（他们有免费版本供您使用）

潜在原因：

磁盘 I/O：您在共享主机上和/或您的服务器磁盘是
有时不可靠/饱和
高峰使用：特定时间的大量流量/查询导致延迟
其他与服务器相关的减速：例如，防病毒或其他进程正在运行并占用资源

如果您能够像我和其他人所建议的那样对您的数据进行更多分析，那么这对于深入了解您的特定问题可能非常有价值

【讨论】：

是的，我确保 EXPLAIN 优化查询和更新使用索引。还检查了表字段的数据类型及其长度，但有时仍然存在问题
您使用的是哪种主机。从目前的信息来看，我怀疑您的磁盘 I/O 可能是个问题。也许便宜/共享主机？
是的，我发现了托管问题。
如果您认为我的答案（其中包括 HOSTING 作为原因）是正确的，请随时将其标记为正确答案。如果您有更多信息或问题，请告诉我。
感谢您的回答，您是否推荐一个工具来监控 Mysql 或监控 Centos 的日志或可能是图形监视器？

【解决方案2】：

对于大数据库，总是要特别注意一些要点；

查看mysql的慢查询日志
检查索引，因为更新索引需要由 RDBMS 再次管理。
检查表字段的数据类型及其长度，因为正确的数据类型也可能导致性能问题。
使用 EXPLAIN 优化查询
根据应用需求选择合适的存储引擎

【讨论】：

是的，我确保 EXPLAIN 优化查询和更新使用索引。还检查了表字段的数据类型及其长度，但仍然有问题

【解决方案3】：

这种不同的结果可能具有网络性质。例如。在 Windows 主机上，您可以尝试使用 '127.0.0.1' 而不是 'localhost'，因为 localhost 默认映射到 IP6 地址，并且它与 MySQL 服务器存在一些问题。

【讨论】：

【解决方案4】：

通过直接php / AJAX调用检查图像/查询的数量，以及页面中包含的JS文件的数量，然后尝试

【讨论】：

不，现在是关于客户端进程。它仅关于 php 后端中的进程。