深圳智汇创想科技有限公司

修改了 预计剩余，旧值为 "0"，新值为 "2"。

修改了 任务描述，区别为：

001- 1. 问题分析华为Gaussdb 智能刊登hwy-zh-gz-gauss-marketpublish：分析发现：主节点：周期性cpu 100%(12:30,4:30,8:30),其他时段cpu60%以下读节点：cpu 60%以下读节点：cpu 60%以下目前华为的已是最高配置：60 vCPUs | 256 GB目前要解决的问题是：把主节点周期性里cpu100% 的问题是，这些周期性cpu100%的sql,如02.sql 慢SQL2.解决方案 目前是批量：DELETE语句平均删除19万行数据，大表删除数据需要修改主键和二级索引，性能差。 解决方案： 2.1 将每次删除17万修改为每次删除1万，delete语句后面增加limit 10000，用delete limit xxx的形式，不要用delete limit xx,xx的方式 2.2 如果改造后CPU还是会打满的话，建议降低这个delete sql操作的并发量3.慢02.sqlDELETE FROM `M_Wish_Express_Shipping_Warehouse`WHERE `CustomerId` = 1 AND `OrderSourceId` = 5950 AND NOT (`ExpressWarehouseId` IN ('5cf219200e4f3a69c3168d97', '5ae99f6f474265387fbae69f', '5f86654c39496907792f23fc', '5f408d4336d382c7c61a42c0', '5f20eb664514cab0485def31', '5ae9a2b30304451b5e9ef395', '5efd50fc221898403adacd0e', '5ae9a3429457a231e5909ad5', '5ae3ba2328644f107e4064da'));4. 此处做记录，方便改造后验证
001+ 1. 问题分析华为Gaussdb 智能刊登hwy-zh-gz-gauss-marketpublish：分析发现：主节点：周期性cpu 100%(12:30,4:30,8:30),其他时段cpu60%以下读节点：cpu 60%以下读节点：cpu 60%以下目前华为的已是最高配置：60 vCPUs | 256 GB目前要解决的问题是：把主节点周期性里cpu100% 的问题是，这些周期性cpu100%的sql,如02.sql 慢SQL2.解决方案 目前是批量：DELETE语句平均删除19万行数据，大表删除数据需要修改主键和二级索引，性能差。 解决方案： 2.1 将每次删除19万修改为每次删除1万，delete语句后面增加limit 10000，用delete limit xxx的形式，不要用delete limit xx,xx的方式 2.2 如果改造后CPU还是会打满的话，建议降低这个delete sql操作的并发量3.慢02.sqlDELETE FROM `M_Wish_Express_Shipping_Warehouse`WHERE `CustomerId` = 1 AND `OrderSourceId` = 5950 AND NOT (`ExpressWarehouseId` IN ('5cf219200e4f3a69c3168d97', '5ae99f6f474265387fbae69f', '5f86654c39496907792f23fc', '5f408d4336d382c7c61a42c0', '5f20eb664514cab0485def31', '5ae9a2b30304451b5e9ef395', '5efd50fc221898403adacd0e', '5ae9a3429457a231e5909ad5', '5ae3ba2328644f107e4064da'));4. 此处做记录，方便改造后验证

001- <p>1. 问题分析<br /><br />华为Gaussdb 智能刊登hwy-zh-gz-gauss-marketpublish：<br />分析发现：<br />主节点：周期性cpu 100%(12:30,4:30,8:30),其他时段cpu60%以下<br />读节点：cpu 60%以下<br />读节点：cpu 60%以下<br /><br /><br /><br />目前华为的已是最高配置：60 vCPUs | 256 GB<br /><br />目前要解决的问题是：<br />把主节点周期性里cpu100% 的问题是，这些周期性cpu100%的sql,<br /><br />如02.sql 慢SQL<br /><br /><br /><br />2.解决方案<br /><br /> 目前是批量：DELETE语句平均删除19万行数据，大表删除数据需要修改主键和二级索引，性能差。<br /><br /> 解决方案：<br /><br /> 2.1 将每次删除17万修改为每次删除1万，delete语句后面增加limit 10000，用delete limit xxx的形式，不要用delete limit xx,xx的方式<br /><br /> 2.2 如果改造后CPU还是会打满的话，建议降低这个delete sql操作的并发量<br /><br /><br />3.慢02.sql<br /><span style="color:#171A1D;">DELETE FROM `M_Wish_Express_Shipping_Warehouse`</span><br /><span style="color:#171A1D;">WHERE `CustomerId` = 1</span><br /><span style="color:#171A1D;"> AND `OrderSourceId` = 5950</span><br /><span style="color:#171A1D;"> AND NOT (`ExpressWarehouseId` IN ('5cf219200e4f3a69c3168d97', '5ae99f6f474265387fbae69f', '5f86654c39496907792f23fc', '5f408d4336d382c7c61a42c0', '5f20eb664514cab0485def31', '5ae9a2b30304451b5e9ef395', '5efd50fc221898403adacd0e', '5ae9a3429457a231e5909ad5', '5ae3ba2328644f107e4064da'));</span><br /><br />4. 此处做记录，方便改造后验证<br /></p>
001+ <p>1. 问题分析<br /><br />华为Gaussdb 智能刊登hwy-zh-gz-gauss-marketpublish：<br />分析发现：<br />主节点：周期性cpu 100%(12:30,4:30,8:30),其他时段cpu60%以下<br />读节点：cpu 60%以下<br />读节点：cpu 60%以下<br /><br /><br /><br />目前华为的已是最高配置：60 vCPUs | 256 GB<br /><br />目前要解决的问题是：<br />把主节点周期性里cpu100% 的问题是，这些周期性cpu100%的sql,<br /><br />如02.sql 慢SQL<br /><br /><br /><br />2.解决方案<br /><br /> 目前是批量：DELETE语句平均删除19万行数据，大表删除数据需要修改主键和二级索引，性能差。<br /><br /> 解决方案：<br /><br /> 2.1 将每次删除19万修改为每次删除1万，delete语句后面增加limit 10000，用delete limit xxx的形式，不要用delete limit xx,xx的方式<br /><br /> 2.2 如果改造后CPU还是会打满的话，建议降低这个delete sql操作的并发量<br /><br /><br />3.慢02.sql<br /><span style="color:#171A1D;">DELETE FROM `M_Wish_Express_Shipping_Warehouse`</span><br /><span style="color:#171A1D;">WHERE `CustomerId` = 1</span><br /><span style="color:#171A1D;"> AND `OrderSourceId` = 5950</span><br /><span style="color:#171A1D;"> AND NOT (`ExpressWarehouseId` IN ('5cf219200e4f3a69c3168d97', '5ae99f6f474265387fbae69f', '5f86654c39496907792f23fc', '5f408d4336d382c7c61a42c0', '5f20eb664514cab0485def31', '5ae9a2b30304451b5e9ef395', '5efd50fc221898403adacd0e', '5ae9a3429457a231e5909ad5', '5ae3ba2328644f107e4064da'));</span><br /><br />4. 此处做记录，方便改造后验证</p>

修改了 总计消耗，旧值为 "0"，新值为 "1"。
修改了 指派给 ，旧值为 "huxiaofeng"，新值为 "chenshaojun"。
修改了 实际完成，旧值为 ""，新值为 "2022-07-27 09:40:21"。
修改了 任务状态，旧值为 "wait"，新值为 "done"。
修改了 实际开始，旧值为 "0000-00-00 00:00:00"，新值为 "2022-07-27 09:40:30"。
修改了 预计剩余，旧值为 "2"，新值为 "0"。
修改了 由谁完成，旧值为 ""，新值为 "chenshaojun"。

修改了 任务状态，旧值为 "done"，新值为 "closed"。
修改了 指派给 ，旧值为 "chenshaojun"，新值为 "closed"。
修改了 由谁关闭，旧值为 ""，新值为 "zhoujie"。
修改了 关闭时间，旧值为 "0000-00-00 00:00:00"，新值为 "2023-10-31 14:53:13"。
修改了 关闭原因，旧值为 ""，新值为 "done"。