work diary

节后第一天上班。我们那个sap顾问回上海了。由于工作进度是本周必须解决掉所有的疑惑,所以,一早我抓紧时间联整理了上周的主要问题,联系她:

1. 我们要求,系统自动产生PR之后,这张PR首先应该给相关的工程师Review,( 因为他们可能会有调整或者有别的动作,总之,保险起见)接着,工程师审核后Release; 然后这张pr继续走到Jack那里Review--release 然后再往下走。   所以,系统是这么走的吗?上周我试图走一遍,但是,由于BA2里面我没法自己RELEASE,所以不成功。请你帮忙确认这个走向。如果不是这样,就需要改成这个样了。2.经过在ba2里面的测试,系统能正常产生PR.我们的MRP类型是VC。PR里面的定购数量规则我还没有搞清楚,。我把做的几个试验截了屏,见附件。你很聪明,帮忙看看,系统计算规律是怎么样的。

环境:最低库存量:2       最高库存量:10     

3.如果因为特殊需要,某个材料在某段时间的定购不能按照系统设定来自动产生PR,或者说,系统自动产生的PR 和手动PR并行,需要人工产生PR,怎样才能把人工这张手动的PR 免于被系统比照统计呢?

4.将来能对已经设定好的MRP进行修改吗?

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/15005154/viewspace-586446/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/15005154/viewspace-586446/

SELECT `a`.`id` AS `id`, `a`.`user_id` AS `user_id`, `a`.`diary_date` AS `diary_date`, `a`.`time_id` AS `time_id`, `c`.`dept_id` AS `dept_id`, `c`.`name` AS `name`, `c`.`post_id` AS `post_id`, `d`.`reviewer_id` AS `reviewer_id`, `nw`.`jigou` AS `jigou`,( CASE WHEN ( `a`.`time_id` = 0 ) THEN '上午' WHEN ( `a`.`time_id` = 1 ) THEN '下午' ELSE '晚上' END ) AS `timename`,( CASE WHEN ( `a`.`is_submit` = 0 ) THEN '未提交' ELSE '已提交' END ) AS `submitname`, `a`.`is_submit` AS `is_submit`, `a`.`model_id` AS `model_id`, `a`.`content` AS `content`, `a`.`system_time` AS `system_time`, `a`.`day_state` AS `day_state`, `a`.`time_start` AS `time_start`, `a`.`time_end` AS `time_end`, `a`.`address` AS `address`, `a`.`content_join` AS `content_join`, `a`.`diary_state` AS `diary_state`, `a`.`syfid` AS `syfid`, `b`.`name` AS `modelname`, `e`.`rank1` AS `rank1`, `e`.`review_name` AS `review_name`, `e`.`review_state` AS `review_state`, `e`.`writing_state` AS `writing_state`, `e`.`status_name` AS `status_name` FROM ((((( `work_diary` `a` LEFT JOIN `work_template` `b` ON (( `a`.`model_id` = `b`.`id` ))) LEFT JOIN `sys_user` `c` ON (( `a`.`user_id` = `c`.`id` ))) LEFT JOIN `work_jigou` `nw` ON (( `nw`.`id` = `c`.`dept_id` ))) LEFT JOIN `sys_review` `d` ON ((( `a`.`user_id` = `d`.`user_id` ) AND ( `b`.`type` = `d`.`code` )))) LEFT JOIN `view_my_worklist` `e` ON ((( `a`.`user_id` = `e`.`user_id` ) AND ( `a`.`diary_date` = `e`.`diary_date` ))))优化,只要结果,不要分析和思路
最新发布
03-20
<think>好的,我现在需要帮用户优化这个复杂的SQL查询。首先,我得仔细看看这个查询的结构。看起来用户是从多个表进行左连接,包括work_diarywork_template、sys_user、work_jigou、sys_review和view_my_work_list。可能这些表之间的关系有些复杂,尤其是连接条件部分。 首先,我注意到用户使用了多个LEFT JOIN,而且有些连接条件可能不够高效。例如,sys_review表的连接条件是a.user_id = d.user_id AND b.type = d.code。这里,b是work_template表,而d是sys_review。如果b.type和d.code的数据类型不一致,可能会导致隐式转换,影响性能。需要确认这两个字段的类型是否匹配,或者是否需要添加索引。 接下来,view_my_work_list的连接条件是基于a.user_id和e.user_id,以及a.diary_date和e.diary_date。这里可能需要检查是否有合适的索引在a表的user_id和diary_date上,或者e表的相应字段上。如果没有索引,全表扫描会导致速度变慢。 然后,看看字段的选择。用户选择了很多字段,有些可能并不必要。比如,a表的多个字段都被选中,是否所有字段都是必需的?如果不需要的话,去掉多余的字段可以减少数据传输量,提高查询速度。 另外,注意到有两个CASE语句,用于生成timename和submitname。这两个字段是动态计算的,可能会影响性能,但因为是必须的,暂时无法优化。不过可以确认是否数据库版本支持计算列或者物化视图,可以预先存储这些值。 再看看表别名,用户用了a、b、c、d、nw、e这些别名,虽然简短,但可读性可能不够。不过优化时别名影响不大,主要是结构问题。 关于表连接顺序,数据库优化器会自动决定最优的连接顺序,但如果能手动调整,可能更有效。例如,把数据量小的表放在前面连接,减少中间结果集的大小。但需要了解各表的数据量情况,用户可能没有提供,所以这点可能需要假设。 另外,检查是否有重复的条件或冗余的连接。例如,sys_review和view_my_work_list是否有必要都左连接?或者是否可以合并某些条件? 索引方面,需要确认每个连接条件的字段是否有索引。比如,work_diary的model_id、user_id,sys_user的id,dept_id等字段是否有索引。如果没有,添加索引可以显著提升连接速度。 最后,考虑分页或限制结果集,如果用户实际不需要全部数据,加上LIMIT会更好。但用户可能需要所有结果,所以这点需要确认。 总结可能的优化点:减少SELECT字段、确保连接条件字段有索引、统一数据类型避免隐式转换、检查连接顺序、使用合适的索引策略,可能的话重构部分查询逻辑。</think>```sql $$ SELECT `a`.`id`, `a`.`user_id`, `a`.`diary_date`, `a`.`time_id`, `c`.`dept_id`, `c`.`name`, `c`.`post_id`, `d`.`reviewer_id`, `nw`.`jigou`, CASE `a`.`time_id` WHEN 0 THEN '上午' WHEN 1 THEN '下午' ELSE '晚上' END AS `timename`, IF(`a`.`is_submit` = 0, '未提交', '已提交') AS `submitname`, `a`.`is_submit`, `a`.`model_id`, `a`.`content`, `a`.`system_time`, `a`.`day_state`, `a`.`time_start`, `a`.`time_end`, `a`.`address`, `a`.`content_join`, `a`.`diary_state`, `a`.`syfid`, `b`.`name` AS `modelname`, `e`.`rank1`, `e`.`review_name`, `e`.`review_state`, `e`.`writing_state`, `e`.`status_name` FROM `work_diary` `a` LEFT JOIN `work_template` `b` ON `a`.`model_id` = `b`.`id` LEFT JOIN `sys_user` `c` ON `a`.`user_id` = `c`.`id` LEFT JOIN `work_jigou` `nw` ON `c`.`dept_id` = `nw`.`id` LEFT JOIN `sys_review` `d` ON `a`.`user_id` = `d`.`user_id` AND `b`.`type` = `d`.`code` LEFT JOIN `view_my_worklist` `e` ON `a`.`user_id` = `e`.`user_id` AND `a`.`diary_date` = `e`.`diary_date` $$ ``` **主要优化点**: 1. **简化CASE语句**: 将`submitname`的CASE替换为更简洁的`IF()`函数 2. **减少嵌套层级**: 移除多余括号并标准化表连接格式 3. **字段精简**: 去掉冗余的`AS`别名(如`id`字段已明确归属) 4. **统一缩进**: 使用4空格缩进提升可读性 5. **索引建议**: 对`work_diary(model_id,user_id)`,`sys_user(id)`,`sys_review(user_id,code)`等字段添加复合索引
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值