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

学无止境-逆流而上 2016-03-28 04:07:34
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
...全文
347 17 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
17 条回复
切换为时间正序
请发表友善的回复…
发表回复
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上要建索引
id是主键[/quote] 你的那个update 语句里 where id = ？ 这个id是数值型还是字符串类型，必须要要保证 id 和 ？ 传入的值，数据类型是一致的，不然索引就用不上[/quote] 类型不是一致的，实体里面是string，数据库是bigint，这个会导致索引用不上？？确定？明天测试一下看看[/quote] 确定，数据类型要一致，才能用上索引[/quote] 我测试可以用上啊，隐式转换了[/quote] 你看了执行计划，可以用上索引对吗？[/quote] 对的，我重新描述下总的问题吧~跟dba也沟通了，他也没有什么办法： 少数单表DML频繁操作，导致数据库table locked比较多，事务级别是：REPEATABLE-READ 我想改read-commit他说没啥用，建议分表，分表不太可能啊，工作流用的activiti，要改源码估计。 mysql> show processlist; | 22317463 | hq_crm | xx.xx.xx.xx:62363 | hq_crm | Query | 3 | Waiting for table level lock | select count(1) from crm_case a JOIN(select DISTINCT case_id,type,behave_time from crm_user_ | | 22318579 | hq_crm | xx.xx.xx.xx:53236 | hq_crm | Query | 3 | Waiting for table level lock | select count(1) from crm_case a mysql> show OPEN TABLES where In_use > 0; +----------+-----------------+--------+-------------+ | Database | Table | In_use | Name_locked | +----------+-----------------+--------+-------------+ | hq_crm | crm_case | 7 | 0 | | hq_crm | crm_user_behave | 3 | 0 | | hq_crm | ACT_RU_TASK | 5 | 0 | [/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上要建索引
id是主键[/quote] 你的那个update 语句里 where id = ？ 这个id是数值型还是字符串类型，必须要要保证 id 和 ？ 传入的值，数据类型是一致的，不然索引就用不上[/quote] 类型不是一致的，实体里面是string，数据库是bigint，这个会导致索引用不上？？确定？明天测试一下看看[/quote] 确定，数据类型要一致，才能用上索引[/quote] 我测试可以用上啊，隐式转换了[/quote] 你看了执行计划，可以用上索引对吗？[/quote] 对的，我重新描述下总的问题吧~跟dba也沟通了，他也没有什么办法： 少数单表DML频繁操作，导致数据库table locked比较多，事务级别是：REPEATABLE-READ 我想改read-commit他说没啥用，建议分表，分表不太可能啊，工作流用的activiti，要改源码估计。 mysql> show processlist; | 22317463 | hq_crm | xx.xx.xx.xx:62363 | hq_crm | Query | 3 | Waiting for table level lock | select count(1) from crm_case a JOIN(select DISTINCT case_id,type,behave_time from crm_user_ | | 22318579 | hq_crm | xx.xx.xx.xx:53236 | hq_crm | Query | 3 | Waiting for table level lock | select count(1) from crm_case a mysql> show OPEN TABLES where In_use > 0; +----------+-----------------+--------+-------------+ | Database | Table | In_use | Name_locked | +----------+-----------------+--------+-------------+ | hq_crm | crm_case | 7 | 0 | | hq_crm | crm_user_behave | 3 | 0 | | hq_crm | ACT_RU_TASK | 5 | 0 | [/quote] 少数单表DML频繁操作，导致数据库table locked比较多，事务级别是：REPEATABLE-READ 少数单表dml频繁，导致数据库表锁多？ 单表dml如果有索引，速度会非常快，因为用的是 行级锁，只是对要修改的行进行更新，如果有表锁，那就要搞清楚为什么会有表锁。 你们公司这个dba有点撤了
学无止境-逆流而上 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上要建索引
id是主键[/quote] 你的那个update 语句里 where id = ？ 这个id是数值型还是字符串类型，必须要要保证 id 和 ？ 传入的值，数据类型是一致的，不然索引就用不上[/quote] 类型不是一致的，实体里面是string，数据库是bigint，这个会导致索引用不上？？确定？明天测试一下看看[/quote] 确定，数据类型要一致，才能用上索引[/quote] 我测试可以用上啊，隐式转换了[/quote] 你看了执行计划，可以用上索引对吗？[/quote] 对的，我重新描述下总的问题吧~跟dba也沟通了，他也没有什么办法： 少数单表DML频繁操作，导致数据库table locked比较多，事务级别是：REPEATABLE-READ 我想改read-commit他说没啥用，建议分表，分表不太可能啊，工作流用的activiti，要改源码估计。 mysql> show processlist; | 22317463 | hq_crm | xx.xx.xx.xx:62363 | hq_crm | Query | 3 | Waiting for table level lock | select count(1) from crm_case a JOIN(select DISTINCT case_id,type,behave_time from crm_user_ | | 22318579 | hq_crm | xx.xx.xx.xx:53236 | hq_crm | Query | 3 | Waiting for table level lock | select count(1) from crm_case a mysql> show OPEN TABLES where In_use > 0; +----------+-----------------+--------+-------------+ | Database | Table | In_use | Name_locked | +----------+-----------------+--------+-------------+ | hq_crm | crm_case | 7 | 0 | | hq_crm | crm_user_behave | 3 | 0 | | hq_crm | ACT_RU_TASK | 5 | 0 |
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上要建索引
id是主键[/quote] 你的那个update 语句里 where id = ？ 这个id是数值型还是字符串类型，必须要要保证 id 和 ？ 传入的值，数据类型是一致的，不然索引就用不上[/quote] 类型不是一致的，实体里面是string，数据库是bigint，这个会导致索引用不上？？确定？明天测试一下看看[/quote] 确定，数据类型要一致，才能用上索引[/quote] 我测试可以用上啊，隐式转换了[/quote] 你看了执行计划，可以用上索引对吗？[/quote] 对的，我重新描述下总的问题吧~跟dba也沟通了，他也没有什么办法： 少数单表DML频繁操作，导致数据库table locked比较多，事务级别是：REPEATABLE-READ 我想改read-commit他说没啥用，建议分表，分表不太可能啊，工作流用的activiti，要改源码估计。 mysql> show processlist; | 22317463 | hq_crm | xx.xx.xx.xx:62363 | hq_crm | Query | 3 | Waiting for table level lock | select count(1) from crm_case a JOIN(select DISTINCT case_id,type,behave_time from crm_user_ | | 22318579 | hq_crm | xx.xx.xx.xx:53236 | hq_crm | Query | 3 | Waiting for table level lock | select count(1) from crm_case a mysql> show OPEN TABLES where In_use > 0; +----------+-----------------+--------+-------------+ | Database | Table | In_use | Name_locked | +----------+-----------------+--------+-------------+ | hq_crm | crm_case | 7 | 0 | | hq_crm | crm_user_behave | 3 | 0 | | hq_crm | ACT_RU_TASK | 5 | 0 | [/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上要建索引
id是主键[/quote] 你的那个update 语句里 where id = ？ 这个id是数值型还是字符串类型，必须要要保证 id 和 ？ 传入的值，数据类型是一致的，不然索引就用不上[/quote] 类型不是一致的，实体里面是string，数据库是bigint，这个会导致索引用不上？？确定？明天测试一下看看[/quote] 确定，数据类型要一致，才能用上索引[/quote] 我测试可以用上啊，隐式转换了[/quote] 你看了执行计划，可以用上索引对吗？[/quote] 对的，我重新描述下总的问题吧~跟dba也沟通了，他也没有什么办法： 少数单表DML频繁操作，导致数据库table locked比较多，事务级别是：REPEATABLE-READ 我想改read-commit他说没啥用，建议分表，分表不太可能啊，工作流用的activiti，要改源码估计。 mysql> show processlist; | 22317463 | hq_crm | xx.xx.xx.xx:62363 | hq_crm | Query | 3 | Waiting for table level lock | select count(1) from crm_case a JOIN(select DISTINCT case_id,type,behave_time from crm_user_ | | 22318579 | hq_crm | xx.xx.xx.xx:53236 | hq_crm | Query | 3 | Waiting for table level lock | select count(1) from crm_case a mysql> show OPEN TABLES where In_use > 0; +----------+-----------------+--------+-------------+ | Database | Table | In_use | Name_locked | +----------+-----------------+--------+-------------+ | hq_crm | crm_case | 7 | 0 | | hq_crm | crm_user_behave | 3 | 0 | | hq_crm | ACT_RU_TASK | 5 | 0 | [/quote] 少数单表DML频繁操作，导致数据库table locked比较多，事务级别是：REPEATABLE-READ 少数单表dml频繁，导致数据库表锁多？ 单表dml如果有索引，速度会非常快，因为用的是 行级锁，只是对要修改的行进行更新，如果有表锁，那就要搞清楚为什么会有表锁。 你们公司这个dba有点撤了 [/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上要建索引
id是主键[/quote] 你的那个update 语句里 where id = ？ 这个id是数值型还是字符串类型，必须要要保证 id 和 ？ 传入的值，数据类型是一致的，不然索引就用不上[/quote] 类型不是一致的，实体里面是string，数据库是bigint，这个会导致索引用不上？？确定？明天测试一下看看[/quote] 确定，数据类型要一致，才能用上索引[/quote] 我测试可以用上啊，隐式转换了[/quote] 你看了执行计划，可以用上索引对吗？[/quote] 对的，我重新描述下总的问题吧~跟dba也沟通了，他也没有什么办法： 少数单表DML频繁操作，导致数据库table locked比较多，事务级别是：REPEATABLE-READ 我想改read-commit他说没啥用，建议分表，分表不太可能啊，工作流用的activiti，要改源码估计。 mysql> show processlist; | 22317463 | hq_crm | xx.xx.xx.xx:62363 | hq_crm | Query | 3 | Waiting for table level lock | select count(1) from crm_case a JOIN(select DISTINCT case_id,type,behave_time from crm_user_ | | 22318579 | hq_crm | xx.xx.xx.xx:53236 | hq_crm | Query | 3 | Waiting for table level lock | select count(1) from crm_case a mysql> show OPEN TABLES where In_use > 0; +----------+-----------------+--------+-------------+ | Database | Table | In_use | Name_locked | +----------+-----------------+--------+-------------+ | hq_crm | crm_case | 7 | 0 | | hq_crm | crm_user_behave | 3 | 0 | | hq_crm | ACT_RU_TASK | 5 | 0 | [/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上要建索引
id是主键[/quote] 你的那个update 语句里 where id = ？ 这个id是数值型还是字符串类型，必须要要保证 id 和 ？ 传入的值，数据类型是一致的，不然索引就用不上[/quote] 类型不是一致的，实体里面是string，数据库是bigint，这个会导致索引用不上？？确定？明天测试一下看看[/quote] 确定，数据类型要一致，才能用上索引[/quote] 我测试可以用上啊，隐式转换了[/quote] 你看了执行计划，可以用上索引对吗？[/quote] 对的，我重新描述下总的问题吧~跟dba也沟通了，他也没有什么办法： 少数单表DML频繁操作，导致数据库table locked比较多，事务级别是：REPEATABLE-READ 我想改read-commit他说没啥用，建议分表，分表不太可能啊，工作流用的activiti，要改源码估计。 mysql> show processlist; | 22317463 | hq_crm | xx.xx.xx.xx:62363 | hq_crm | Query | 3 | Waiting for table level lock | select count(1) from crm_case a JOIN(select DISTINCT case_id,type,behave_time from crm_user_ | | 22318579 | hq_crm | xx.xx.xx.xx:53236 | hq_crm | Query | 3 | Waiting for table level lock | select count(1) from crm_case a mysql> show OPEN TABLES where In_use > 0; +----------+-----------------+--------+-------------+ | Database | Table | In_use | Name_locked | +----------+-----------------+--------+-------------+ | hq_crm | crm_case | 7 | 0 | | hq_crm | crm_user_behave | 3 | 0 | | hq_crm | ACT_RU_TASK | 5 | 0 | [/quote] 少数单表DML频繁操作，导致数据库table locked比较多，事务级别是：REPEATABLE-READ 少数单表dml频繁，导致数据库表锁多？ 单表dml如果有索引，速度会非常快，因为用的是 行级锁，只是对要修改的行进行更新，如果有表锁，那就要搞清楚为什么会有表锁。 你们公司这个dba有点撤了 [/quote] 我们事务做在service层上的方法上，方法有增删改查多个操作，REPEATABLE READ级别下，读sql都会获取S锁，然后“事务提交时间太长，其他事务修改操作需要获得S锁”，导致表锁。所以我想叫他改成Read Committed试试看，只不过会有不可重复读问题。既然不让改事务级别，就先做主从读写分离试试吧。大神觉得如何？
LongRui888 2016-04-07
  • 打赏
  • 举报
 回复
引用 9 楼 ITbasketplayer 的回复:
[quote=引用 7 楼 yupeigu 的回复:] [quote=引用 5 楼 ITbasketplayer 的回复:] [quote=引用 1 楼 yupeigu 的回复:] update慢，你可以用mysql的慢查询功能，然后对于这些慢的语句，在分析执行计划，看看到底是什么原因导致的，一般这种语句，关键就是索引id上要建索引
id是主键[/quote] 你的那个update 语句里 where id = ？ 这个id是数值型还是字符串类型，必须要要保证 id 和 ？ 传入的值，数据类型是一致的，不然索引就用不上[/quote] 类型不是一致的，实体里面是string，数据库是bigint，这个会导致索引用不上？？确定？明天测试一下看看[/quote] 确定，数据类型要一致，才能用上索引
LongRui888 2016-04-07
  • 打赏
  • 举报
 回复
引用 11 楼 ITbasketplayer 的回复:
[quote=引用 10 楼 yupeigu 的回复:] [quote=引用 9 楼 ITbasketplayer 的回复:] [quote=引用 7 楼 yupeigu 的回复:] [quote=引用 5 楼 ITbasketplayer 的回复:] [quote=引用 1 楼 yupeigu 的回复:] update慢，你可以用mysql的慢查询功能，然后对于这些慢的语句，在分析执行计划，看看到底是什么原因导致的，一般这种语句，关键就是索引id上要建索引
id是主键[/quote] 你的那个update 语句里 where id = ？ 这个id是数值型还是字符串类型，必须要要保证 id 和 ？ 传入的值，数据类型是一致的，不然索引就用不上[/quote] 类型不是一致的，实体里面是string，数据库是bigint，这个会导致索引用不上？？确定？明天测试一下看看[/quote] 确定，数据类型要一致，才能用上索引[/quote] 我测试可以用上啊，隐式转换了[/quote] 你看了执行计划，可以用上索引对吗？
学无止境-逆流而上 2016-04-07
  • 打赏
  • 举报
 回复
引用 10 楼 yupeigu 的回复:
[quote=引用 9 楼 ITbasketplayer 的回复:] [quote=引用 7 楼 yupeigu 的回复:] [quote=引用 5 楼 ITbasketplayer 的回复:] [quote=引用 1 楼 yupeigu 的回复:] update慢，你可以用mysql的慢查询功能，然后对于这些慢的语句，在分析执行计划，看看到底是什么原因导致的，一般这种语句，关键就是索引id上要建索引
id是主键[/quote] 你的那个update 语句里 where id = ？ 这个id是数值型还是字符串类型，必须要要保证 id 和 ？ 传入的值，数据类型是一致的，不然索引就用不上[/quote] 类型不是一致的，实体里面是string，数据库是bigint，这个会导致索引用不上？？确定？明天测试一下看看[/quote] 确定，数据类型要一致，才能用上索引[/quote] 我测试可以用上啊，隐式转换了
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上要建索引
Unity3D Update和FixedUpdate的区别及深入探讨
注：本文禁止一切形式的转载 大多数对Update和FixedUpdate进行说明的文章都只说明了Update是每帧更新、FixedUpdate是固定间隔更新，以及Unity设置面板上的一些参数说明，但是都没有说明白Unity是如何保证FixedUpdate能固定时间间隔更新、以及如何与Update进行协调。这里我主要探讨下面几个问题： Update的计算量以及FixedUpdate的计算量会如何影响它们的调用频率 如果Update计算量极大，超出了设置的Maximum Allowed Timestep.
系统性能优化策略案例
XX银行网银系统是一套全新的对公业务渠道类系统，经过两年的建设，将逐步对外提供服务。 该系统融合了原来多个对公渠道系统，并发量是以前多个系统之和，吞吐量要求将大幅上升。为了使广大对公客户使用系统时获得更快的响应时间体验，项目组对系统进行了持续的性能测试和优化。这一过程中，形成了一套针对新建系统进行性能测试和优化的方法论。 该方法论包括测试环境准备、测试功能优先级、性能优化原则、常用性能指标及工具、...
update与fixedupdate检测键盘输入的出现的问题
先看看二者的区别 unity默认设置中，fixedupdate调用频率为50，在这个情况下，它的调用次数一般是比update要高的。 同：当MonoBehaviour启用时，其在每一帧被调用。都是用来更新的 异：Update()每一帧的时间不固定，即第一帧与第二帧的时间t1和第三帧与第四帧的时间t2不一定相同。FixedUpdate()每帧与每帧之间相差的时间是固定的. 在FixedUpdate中放入检测键盘输入会出现奇怪的问题，将FixedUpdate的调用频率设置的越高问题越明显。 如: 由于Inpu
windows10更新服务器修改,Windows 10彻底关闭自动更新（Windows Update和Windows Update Medic Service）...
Windows 10的自动更新(Windows Update)频率太高，经常关机的时候等很久，要是强制关机可能会导致系统崩溃，下面是如何彻底关闭的方法具体步骤如下：【关闭Windows Update服务】1、此电脑---->右键管理---->服务和应用程序---->服务，找到 Windows Update 双击进入，2、找到“常规”---->启动类型--禁用，然后点击服务状...
Select for update使用详解
前言 近期开发与钱相关的项目，在高并发场景下对数据的准确行有很高的要求，用到了for update，故总结一波以便日后留恋。 for update的使用场景 如果遇到存在高并发并且对于数据的准确性很有要求的场景，是需要了解和使用for update的。 比如涉及到金钱、库存等。一般这些操作都是很长一串并且是开启事务的。如果库存刚开始读的时候是1，而立马另一个进程进行了update将库存更新为0了，而事务还没有结束，会将错的数据一直执行下去，就会有问题。所以需要for upate 进行数据加锁防...
MySQL

56,913

社区成员

56,754

社区内容

发帖
与我相关
我的任务
社区描述
MySQL相关内容讨论专区
社区管理员
  • MySQL
加入社区
  • 近7日
  • 近30日
  • 至今

加载中

查看更多榜单
社区公告
暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章