work diary

这一天过的比较充实,虽然取得的结果很微小---很有可能已经是May或别人早已经意识到的。

早晨call Julia,讨论修改预防项维修的work order 类型问题。我们部门有很大一部分的预防项维修是在装置运转前就已经建立,当时由Julia通过系统批量导入到sap里面去。Work order 类型选的是 WAPM , ActivTyp类型选的是PRV. 在当时,这是正确的。但是,08年年底,系统重新作了个改变,预防性维修的类型就改成:WANW PRO了。现在,新的WAPM已经成为大修的代码了。由于预防项维修的工单使按时间源源不断自动跳出来,新产生的工单仍旧是老样子自动选用WAPM作为工单代码,并没有同步更新,这样,预防性维修的费用就被划分到大修费用里面去了。造成大修费用的不准确。这点是编程序的人所没有考虑到的,或者说,他们没有料到我们要进行成本的划分。

 

整个已经建立好的预防性维修的Item有大约2000多条。如果要人工更改,是个大作业;而且,已经关闭的预防项维修工单使不能再作更改的。如果需要sap 平台编程序更改,也需要一段时间的。

 

以上是问题一。

 

接下来,我在sap里面仔细筛选,查看。

如果,通过设定“create by”来筛选,可以把历史的预防项维修的工单单独调出来。因为,系统批量导入的预防性维修的工单的创建者都是以“IP*****”为名称的。

但是,主要是X的工单代码选择有很大的问题,他们的工单代码选择很随意,预防性维修不是按Task list/item/plan/schedule的步骤建立,而是以零星的工单形式手动建立,这就没有达到我们建立自动预防性维修的目的。而其他的工单类型填写也没有按约定来填。

 

即使我通过create bys筛选出了系统的工单,那些手动的工单会错过,大修的工单里面不可避免的混杂了各种非大修的工单。大修费用理不清楚。

这是问题二。

 

怎么解决?

我打算列张表,stupid 表,明明白白列出组合,规定作工单的人不可随意;今天是26号,如果执行顺利,三月份的工单就能够清清楚楚了。

0912月份的工单,只能尽量了。估计全部理清楚是不可能的。

Julia那儿的程序,看情况,如果需要继续,就让他们继续编程。

 

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

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

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、付费专栏及课程。

余额充值