mysql 大量更新请求 updating 状态

[sujin190]

每秒大概 100 个更新， 200 万左右数据，每次都是有索引更新，每次更新一条记录，大量处于 updating ， mysql 更新操作有这么慢么？还好多都更新等待超时了，或者该怎么找出哪的问题么？

[msg7086]

SSD ？

[peter999]

是事务表吗？

[Lpl]

你查查目前更新的语句，是不是卡在某个 sql 上了？

[sujin190]

@msg7086 普通磁盘，磁盘 io 不高啊

[sujin190]

@peter999 事务表？

[sujin190]

@Lpl 没有，只是每个都很慢，经常等待几十秒的

[lj0014]

innodb 还是 myisam

[sujin190]

@lj0014 innodb

[lecher]

索引重建的成本太高？建个测试环境试试删除索引后的更新耗时。看看具体的 SQL 和索引。
简单粗暴 SSD ，应该效果拔群。

[noahzh]

索引更新指的是更新索引,还是通过索引更新?

[sujin190]

@noahzh 通过索引更新，更新的不是索引字段

[sujin190]

@lecher 根据有索引的字段更新，但跟更新的不是索引字段，有索引的字段 insert 之后就没有更新过了，这种情况除了 io 问题之外还有可能是其他问题么？更新的那个字段默认是 null ，更新之后有值，这种情况有有限么？

[cevincheung]

postgresql 。

[sujin190]

@lecher varchar 类型，更新之后值不超过 64 字符

[lecher]

那只能拆解问题了。
update 毕竟分两步，先查后改。如果每次只是根据索引更新一条，试试拆成查询看看查询消耗。

如果不是需要重建索引，感觉问题很可能出现在查询这块的消耗上。用 EXPLAIN 分析一下操作的影响行数，如果建的索引用得好，查询的影响行数估计就只有几个。


之后才是测试取单行的标识 id 直接做更新操作， varchar 是变长字段，改动是会影响行数据的长度的。但应该不会出现那么大的耗时。

[sujin190]

@lecher 根据索引更新，是唯一索引，所以每次肯定也只影响一行，其实平常是正常的，只是并发稍高一些的时候会慢，但看 cpu 和磁盘 io 似乎并不高，每秒大概两三百写， cpu 10%左右，这样应该不算高吧？

[wuyadong]

这种情况，我一般先全部 delete 掉，然后在 insert ，最后重建索引， update 很慢。

[sujin190]

@wuyadong 可是不能删。。

[likuku]

InnoDB 相关设定，都默认的么？

[likuku]

机器硬件信息，请提供:
CPU/核数量，内存大小，硬盘类型，文件系统类型

mysql 的运行时参数值：
innodb_buffer_pool_size
innodb_log_file_size
innodb_flush_method
innodb_flush_log_at_trx_commit

可参考：
http://mp.weixin.qq.com/s?__biz=MzA4Nzg5Nzc5OA==&mid=206762682&idx=1&sn=1233ed1496d7fd059d247329f3d3a183&scene=1&key=c76941211a49ab587d35d0d840a84ff2e3948510bca7698783e134b95c3e8ad0a30d1f83897e9c764e289a1011c565db&ascene=0&uin=Mjk1ODMyNTYyMg%3D%3D&devicetype=iMac+MacBookPro9%2C2+OSX+OSX+10.10.3+build(14D136)&version=11020012&pass_ticket=GJi1zStfd3iFy8nPiSm73eDDCYHehF3pnzgmnpzERbyqm7LlmMscbVsBrAMC%2FPt3