频率很高的update系统如何优化

2016-03-28 04:07:34 394 阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›

同花顺【红绿趋势】幅图指标源码分析 a10:IF(差值<=0 ,0 ,差值*0.2 ,4 ,0),STICK,linethick5,colorred;a7:IF(差值<=0 ,0 ,差值*0.8 ,4 ,0),STICK,linethick5,colorred;a8:IF(差值<=0 ,0 ,差值*0.6 ,4 ,0),STICK,linethick5,colorred;a6:IF(差值<=0 ,0 ,差值*1 ,4 , 0),STICK,linethick5,colorred;DRAWICON(先锋<0,-25,1); 阅读详情

50W数据的一个表，系统运行时，大量update case set visit = ?, due_date = ?, update_by = ?, update_date = ? WHERE id = ? 语句，监控到同一个update 语句时间很不稳定，经常很慢，目前代码上面已做到优化，但是因为系统是crm系统，流程job+数据流入+大量客服使用系统，导致大量update业务操作无法避免，想从数据库层面做一些优化，求一些建议。mysql是innodb。
2016-03-28 14:12:54,027 [HandleTimeService.java:56] - case update spend 3593ms,caseId:496344
2016-03-28 14:12:57,682 [HandleTimeService.java:56] - case update spend 3649ms,caseId:496309
2016-03-28 14:12:57,676 [HandleTimeService.java:56] - case update spend 3642ms,caseId:496032
2016-03-28 14:12:57,684 [HandleTimeService.java:56] - case update spend 3654ms,caseId:496309
2016-03-28 14:13:00,510 [HandleTimeService.java:56] - case update spend 683ms,caseId:496333
2016-03-28 14:13:00,701 [HandleTimeService.java:56] - case update spend 182ms,caseId:496031
2016-03-28 14:13:11,005 [HandleTimeService.java:56] - case update spend 5444ms,caseId:495848
2016-03-28 14:13:15,130 [HandleTimeService.java:56] - case update spend 4109ms,caseId:467920
2016-03-28 14:13:17,525 [HandleTimeService.java:56] - case update spend 2383ms,caseId:495767
2016-03-28 14:13:21,197 [HandleTimeService.java:56] - case update spend 3680ms,caseId:496307
2016-03-28 14:13:21,891 [HandleTimeService.java:56] - case update spend 699ms,caseId:496346
2016-03-28 14:13:21,887 [HandleTimeService.java:56] - case update spend 697ms,caseId:496347
2016-03-28 14:13:21,892 [HandleTimeService.java:56] - case update spend 699ms,caseId:255415
2016-03-28 14:13:22,013 [HandleTimeService.java:56] - case update spend 119ms,caseId:496254
2016-03-28 14:13:26,365 [HandleTimeService.java:56] - case update spend 3798ms,caseId:496305

...全文

Vue3 + MQTT.js 实现 SCADA 实时数据通信：从不稳定到稳定的完整实践本文介绍了SCADA组态引擎开发中MQTT协议的应用及优化实践。项目采用MQTT协议实现工业设备数据采集与可视化，但面临连接不稳定、数据格式多样化和数据绑定复杂三大问题。针对MQTT连接问题，分析发现超时设置过短（原8秒）、缺少客户端超时配置和心跳机制是主要原因。优化方案包括：协议转换（mqtt://→ws://）、双重超时保护（15秒手动+30秒客户端）、60秒心跳间隔等，显著提升了连接稳定性。通过完整代码实现展示了连接配置、认证处理和错误处理机制，为物联网数据传输提供了可靠解决方案。阅读详情

学无止境-逆流而上

MySQL 57,062 成员 56,759 内容

+ 关注 + 加入社区

切换为时间正序

LongRui888 2016-04-11

打赏
举报

引用 13 楼 ITbasketplayer 的回复:

[quote=引用 12 楼 yupeigu 的回复:] [quote=引用 11 楼 ITbasketplayer 的回复:] [quote=引用 10 楼 yupeigu 的回复:] [quote=引用 9 楼 ITbasketplayer 的回复:] [quote=引用 7 楼 yupeigu 的回复:] [quote=引用 5 楼 ITbasketplayer 的回复:] [quote=引用 1 楼 yupeigu 的回复:] update慢，你可以用mysql的慢查询功能，然后对于这些慢的语句，在分析执行计划，看看到底是什么原因导致的，一般这种语句，关键就是索引id上要建索引

引用 13 楼 ITbasketplayer 的回复:

[quote=引用 12 楼 yupeigu 的回复:] [quote=引用 11 楼 ITbasketplayer 的回复:] [quote=引用 10 楼 yupeigu 的回复:] [quote=引用 9 楼 ITbasketplayer 的回复:] [quote=引用 7 楼 yupeigu 的回复:] [quote=引用 5 楼 ITbasketplayer 的回复:] [quote=引用 1 楼 yupeigu 的回复:] update慢，你可以用mysql的慢查询功能，然后对于这些慢的语句，在分析执行计划，看看到底是什么原因导致的，一般这种语句，关键就是索引id上要建索引

学无止境-逆流而上 2016-04-11

打赏
举报

引用 12 楼 yupeigu 的回复:

[quote=引用 11 楼 ITbasketplayer 的回复:] [quote=引用 10 楼 yupeigu 的回复:] [quote=引用 9 楼 ITbasketplayer 的回复:] [quote=引用 7 楼 yupeigu 的回复:] [quote=引用 5 楼 ITbasketplayer 的回复:] [quote=引用 1 楼 yupeigu 的回复:] update慢，你可以用mysql的慢查询功能，然后对于这些慢的语句，在分析执行计划，看看到底是什么原因导致的，一般这种语句，关键就是索引id上要建索引

LongRui888 2016-04-11

打赏
举报

另外，最后如果实在没办法，读写分离也是个好办法，不过，这个又会有新的问题，到时候数据可能会有不一致的问题，不过这个就是dba的问题了，不是你的问题了

LongRui888 2016-04-11

打赏
举报

引用 15 楼 ITbasketplayer 的回复:

[quote=引用 14 楼 yupeigu 的回复:] [quote=引用 13 楼 ITbasketplayer 的回复:] [quote=引用 12 楼 yupeigu 的回复:] [quote=引用 11 楼 ITbasketplayer 的回复:] [quote=引用 10 楼 yupeigu 的回复:] [quote=引用 9 楼 ITbasketplayer 的回复:] [quote=引用 7 楼 yupeigu 的回复:] [quote=引用 5 楼 ITbasketplayer 的回复:] [quote=引用 1 楼 yupeigu 的回复:] update慢，你可以用mysql的慢查询功能，然后对于这些慢的语句，在分析执行计划，看看到底是什么原因导致的，一般这种语句，关键就是索引id上要建索引

引用 13 楼 ITbasketplayer 的回复:

[quote=引用 12 楼 yupeigu 的回复:] [quote=引用 11 楼 ITbasketplayer 的回复:] [quote=引用 10 楼 yupeigu 的回复:] [quote=引用 9 楼 ITbasketplayer 的回复:] [quote=引用 7 楼 yupeigu 的回复:] [quote=引用 5 楼 ITbasketplayer 的回复:] [quote=引用 1 楼 yupeigu 的回复:] update慢，你可以用mysql的慢查询功能，然后对于这些慢的语句，在分析执行计划，看看到底是什么原因导致的，一般这种语句，关键就是索引id上要建索引

[/quote] 我们事务做在service层上的方法上，方法有增删改查多个操作，REPEATABLE READ级别下，读sql都会获取S锁，然后“事务提交时间太长，其他事务修改操作需要获得S锁”，导致表锁。所以我想叫他改成Read Committed试试看，只不过会有不可重复读问题。既然不让改事务级别，就先做主从读写分离试试吧。大神觉得如何？[/quote] 可重复读是指在同一个事务中，2次同样的sql，查询出来的数据不一样，一般来说如果是sql server，为了实现可重复读，是通过在事务中对所要读取的行加上S锁，直到事务结束，才释放S锁，注意是行级别的，不是表级别的S锁，不需要锁定表。所以，这里主要看你的业务sql中，是否有一个事务中，同时读取2次，另外，是否会先读取数据，然后再对数据判断，看是否要update，如果有这种操作，那么也是不需要锁定表的，只是需要对所要读取的行通过加上 X锁，就能实现。

学无止境-逆流而上 2016-04-11

打赏
举报

引用 14 楼 yupeigu 的回复:

[quote=引用 13 楼 ITbasketplayer 的回复:] [quote=引用 12 楼 yupeigu 的回复:] [quote=引用 11 楼 ITbasketplayer 的回复:] [quote=引用 10 楼 yupeigu 的回复:] [quote=引用 9 楼 ITbasketplayer 的回复:] [quote=引用 7 楼 yupeigu 的回复:] [quote=引用 5 楼 ITbasketplayer 的回复:] [quote=引用 1 楼 yupeigu 的回复:] update慢，你可以用mysql的慢查询功能，然后对于这些慢的语句，在分析执行计划，看看到底是什么原因导致的，一般这种语句，关键就是索引id上要建索引

引用 13 楼 ITbasketplayer 的回复:

[quote=引用 12 楼 yupeigu 的回复:] [quote=引用 11 楼 ITbasketplayer 的回复:] [quote=引用 10 楼 yupeigu 的回复:] [quote=引用 9 楼 ITbasketplayer 的回复:] [quote=引用 7 楼 yupeigu 的回复:] [quote=引用 5 楼 ITbasketplayer 的回复:] [quote=引用 1 楼 yupeigu 的回复:] update慢，你可以用mysql的慢查询功能，然后对于这些慢的语句，在分析执行计划，看看到底是什么原因导致的，一般这种语句，关键就是索引id上要建索引

LongRui888 2016-04-07

打赏
举报

引用 9 楼 ITbasketplayer 的回复:

[quote=引用 7 楼 yupeigu 的回复:] [quote=引用 5 楼 ITbasketplayer 的回复:] [quote=引用 1 楼 yupeigu 的回复:] update慢，你可以用mysql的慢查询功能，然后对于这些慢的语句，在分析执行计划，看看到底是什么原因导致的，一般这种语句，关键就是索引id上要建索引

LongRui888 2016-04-07

打赏
举报

引用 11 楼 ITbasketplayer 的回复:

[quote=引用 10 楼 yupeigu 的回复:] [quote=引用 9 楼 ITbasketplayer 的回复:] [quote=引用 7 楼 yupeigu 的回复:] [quote=引用 5 楼 ITbasketplayer 的回复:] [quote=引用 1 楼 yupeigu 的回复:] update慢，你可以用mysql的慢查询功能，然后对于这些慢的语句，在分析执行计划，看看到底是什么原因导致的，一般这种语句，关键就是索引id上要建索引

学无止境-逆流而上 2016-04-07

打赏
举报

引用 10 楼 yupeigu 的回复:

[quote=引用 9 楼 ITbasketplayer 的回复:] [quote=引用 7 楼 yupeigu 的回复:] [quote=引用 5 楼 ITbasketplayer 的回复:] [quote=引用 1 楼 yupeigu 的回复:] update慢，你可以用mysql的慢查询功能，然后对于这些慢的语句，在分析执行计划，看看到底是什么原因导致的，一般这种语句，关键就是索引id上要建索引

LongRui888 2016-04-06

打赏
举报

另外，能否把这个update语句的执行计划打印出来看看，类似如下： explain update 。。。

LongRui888 2016-04-06

打赏
举报

引用 5 楼 ITbasketplayer 的回复:

[quote=引用 1 楼 yupeigu 的回复:] update慢，你可以用mysql的慢查询功能，然后对于这些慢的语句，在分析执行计划，看看到底是什么原因导致的，一般这种语句，关键就是索引id上要建索引

id是主键[/quote] 你的那个update 语句里 where id = ？这个id是数值型还是字符串类型，必须要要保证 id 和？传入的值，数据类型是一致的，不然索引就用不上

学无止境-逆流而上 2016-04-06

打赏
举报

引用 7 楼 yupeigu 的回复:

[quote=引用 5 楼 ITbasketplayer 的回复:] [quote=引用 1 楼 yupeigu 的回复:] update慢，你可以用mysql的慢查询功能，然后对于这些慢的语句，在分析执行计划，看看到底是什么原因导致的，一般这种语句，关键就是索引id上要建索引

id是主键[/quote] 你的那个update 语句里 where id = ？这个id是数值型还是字符串类型，必须要要保证 id 和？传入的值，数据类型是一致的，不然索引就用不上[/quote] 类型不是一致的，实体里面是string，数据库是bigint，这个会导致索引用不上？？确定？明天测试一下看看

ACMAIN_CHM 2016-04-06

打赏
举报

如果打算通过其它方面进行优化，则必须先试验分析产生问题的原因到底是什么。建议楼主在相同数据库内创建另外一表，模拟50W记录进行 update以断定是仅这个表`case`有这个问题，还是所以update有这个问题。产生问题的可能性因素很多。比如锁，磁盘IO瓶颈， INNODB初始文件增长设置不合理等等。

学无止境-逆流而上 2016-04-05

打赏
举报

引用 1 楼 yupeigu 的回复:

update慢，你可以用mysql的慢查询功能，然后对于这些慢的语句，在分析执行计划，看看到底是什么原因导致的，一般这种语句，关键就是索引id上要建索引

id是主键

学无止境-逆流而上 2016-04-05

打赏
举报

引用 3 楼 ACMAIN_CHM 的回复:

WHERE id = ? ID是主键吗？如果是，建议考虑分区表。

sql就很简单，id是主键，50W就分，DBA也说服不了吧

ACMAIN_CHM 2016-03-28

打赏
举报

WHERE id = ? ID是主键吗？如果是，建议考虑分区表。

benluobo 2016-03-28

打赏
举报

explain语句贴出结果 update慢有可能是定位行的操作慢，也有可能本身就是更新慢

LongRui888 2016-03-28

打赏
举报

update慢，你可以用mysql的慢查询功能，然后对于这些慢的语句，在分析执行计划，看看到底是什么原因导致的，一般这种语句，关键就是索引id上要建索引

频率很高的update系统如何优化

相关推荐