我试图以更易读的格式返回查询结果。我的查询返回作业完成的平均时间长度以及作业完成的实际时间长度（但仅当实际＆gt;平均值时;换句话说，它＆＃39;寻找比正常时间更长的工作来完成并报告平均和实际运行时间。数据库将时间值存储为以纪元为单位的时间（以毫秒为单位），因此我尝试将其从毫秒转换为分钟，以使事物更具人性化。
但是，我得到了奇怪的结果。有时，actual_run_time_in_min会小于avg_run_time_in_min，即使这是不可能的。如果是这种情况，它将 NOT 返回值。我确定这个问题与我进行mysql算法的方式有关，但我不知道如何修复它。
注意：我还添加了一个乘数（当前设置为1.4）以增加平均运行时间，以确保给定作业明确超出预期运行时间。 < / p>
select distinct a.name,
TRUNCATE(((t.avgtime / 1000) % 60), 2) as avg_run_time_in_min,
TRUNCATE(((($CURRENT_TIME - jh.start_time) / 1000) % 60), 2) as actual_run_time_in_min
from application a
join job_history jh on a.id = jh.application_id
join (
select application_id, (avg(end_time - start_time) * $MULTIPLIER) as avgtime
from job_history
where status = 'SUCCESS'
group by application_id
) t on a.id = t.application_id
where jh.status = 'EXECUTING' and
($CURRENT_TIME - jh.start_time) > t.avgtime;
以下是一些示例数据：
表1
+--------+------------+---------------+---------------+----------------+
| job_id | status | start_time | end_time | application_id |
+--------+------------+---------------+---------------+----------------+
| job1 | successful | 1466064475349 | 1466064580885 | app1 |
| job2 | failed | 1470811395368 | 1470811491037 | app2 |
| job3 | successful | 1439886075453 | 1439886081649 | app1 |
| job4 | executing | 1470804777264 | 0 | app1 |
| job5 | successful | 1470799667312 | 1470799763746 | app3 |
+--------+------------+---------------+---------------+----------------+
表2
+------+------------------+
| id | name |
+------+------------------+
| app1 | Team Green's app |
| app2 | Team Blue's app |
| app3 | Team Red's app |
+------+------------------+
以下是一些实际结果（不基于上面的示例数据）：
+---------------+---------------------+------------------------+
| name | avg_run_time_in_min | actual_run_time_in_min |
+---------------+---------------------+------------------------+
| red-team | 26.50 | 48.03 |
| green-team | 44.75 | 5.74 |
+---------------+---------------------+------------------------+
如你所见，第一排看起来不错;但是，在第二行中，实际时间小于平均时间。有趣的是，尽管算术存在明显的问题，但这两项工作是两项工作（其中很多）超过了平均运行时间。因此，查询返回正确的结果。