嘿，我来帮你分析下这个统计结果不稳定的问题——明明没有初级员工却偶尔算出1个，资深员工数还少了，结果时对时错确实挺头疼的。结合你的表结构、SQL语句和描述，我梳理了几个最可能的原因，还有对应的验证和解决方法：

1. 并发事务导致的脏读 #

这是结果不稳定最常见的诱因。如果你的MySQL事务隔离级别是Read Uncommitted（读未提交），或者有其他未提交的修改操作在运行，统计语句可能会读取到还没确认的脏数据：

• 比如有同事正在临时调整某个员工的junior状态（改成1测试后又改回0），或者临时插入/删除slotwork的关联记录，这些未提交的操作会被你的统计语句捕获，导致结果出错；当事务回滚或提交后，数据恢复正常，统计结果就又对了。
• 你可以先查下当前会话的隔离级别：

SELECT @@transaction_isolation;

如果是READ-UNCOMMITTED，建议改成READ-COMMITTED来避免脏读。

2. slotwork表存在无效关联记录 #

你的统计依赖slotwork和worker的关联，如果slotwork里有以下情况，会直接导致统计偏差：

• 关联到错误的员工：比如slotwork.FK_worker的值是无效数字（比如0）或者非数字字符串，而你的worker表刚好有EmployeeID=0且junior=1的记录，这时INNER JOIN会错误地把这条无效关联算成初级员工，同时挤占了一个资深员工的统计名额（因为这条错误记录不会被计入资深统计）。
• 临时的重复/无效记录：比如某个脚本在运行时临时插入了关联记录，之后又删除，统计时机不同，结果就会不一样。

你可以验证这一点：先查有问题的班次（比如452）的所有关联记录：

SELECT * FROM slotwork WHERE FK_SlotNo = 452;

再检查这些FK_worker对应的员工信息：

SELECT EmployeeID, junior FROM worker WHERE EmployeeID IN (SELECT FK_worker FROM slotwork WHERE FK_SlotNo = 452);

看看有没有junior=1的员工，或者有没有FK_worker对应的员工不存在（不过INNER JOIN会过滤掉后者，重点看存在的员工的junior值）。

3. worker表的junior字段存在NULL值 #

你的worker表中junior字段默认是0，但如果有员工的junior值被改成了NULL（比如插入时没指定该字段，或者手动更新失误），会影响统计逻辑：

• 统计资深员工时，CASE WHEN worker.junior = 0 THEN 1 END会因为NULL != 0返回NULL，COUNT会忽略这条记录，导致资深数少1；
• 统计初级员工时，CASE WHEN worker.junior = 1 THEN 1 END也会返回NULL，COUNT会忽略，所以初级数应该是0，但如果同时存在前面说的无效关联，就会出现初级数为1的矛盾结果。

你可以查下worker表中junior为NULL的记录：

SELECT * FROM worker WHERE junior IS NULL;

针对你的统计需求，我建议调整SQL语句让它更健壮，同时解决潜在问题：

1. 用SUM替代COUNT，逻辑更直观，同时处理NULL值（把NULL视为资深员工，符合你的默认设置）：

SELECT 
  sw.FK_SlotNo,
  SUM(CASE WHEN w.junior = 1 THEN 1 ELSE 0 END) AS junior_count,
  SUM(CASE WHEN w.junior = 0 OR w.junior IS NULL THEN 1 ELSE 0 END) AS senior_count
FROM slotwork sw
INNER JOIN worker w ON sw.FK_worker = w.EmployeeID
GROUP BY sw.FK_SlotNo;

2. 确保slotwork.FK_worker和worker.EmployeeID的字段类型完全一致，避免隐式转换导致的错误匹配。
3. 调整事务隔离级别为READ-COMMITTED，避免脏读：

-- 会话级设置
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
-- 全局级设置（需要权限）
SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;

内容的提问来源于stack exchange，提问作者Stumbler