用MySQL+Power BI搭一套员工流失预警系统

员工离职的成本有多高？业内有个粗略估算：替换一名核心员工的成本，通常是他年薪的1.5到2倍。这还没算上团队士气受损、项目延期这些隐性代价。对HR部门来说，提前识别" flight risk "（离职风险人群）从来不是锦上添花，而是刚需。

最近我用经典的IBM HR Analytics数据集（1470名员工，35个特征字段），完整走了一遍从原始数据到高管决策看板的全流程。这套方法可以直接迁移到任何用MySQL做数据仓库、Power BI做可视化的企业环境。

整个项目分五步：数据库接入与质检 → 数据清洗与视图构建 → SQL分层分析 → Power BI建模 → 业务洞察输出。下面展开每一步的具体操作。

第一步：MySQL入库与数据质检

企业级数据活在关系型数据库里，不是Excel。我先用MySQL Workbench建了本地schema，把CSV导进去。跑任何指标之前，先做"sanity check"——用EmployeeNumber这个唯一主键查重复记录：

SELECT EmployeeNumber, COUNT(*)
FROM hr_employee_attrition
GROUP BY EmployeeNumber
HAVING COUNT(*) > 1;

结果：0条重复。数据结构干净，可以往下走。

第二步：建清洗视图，别让BI工具背脏数据的锅

常见错误是把未经清洗的数据直接丢给Power BI，导致性能拖沓。我在数据库层建了永久视图vw_hr_attrition_clean，做两件事：一、删掉零方差列（比如StandardHours，全员都是80小时）；二、把文本字段转二进制标记（1和0）。

CREATE VIEW vw_hr_attrition_clean AS
SELECT
EmployeeNumber, Age, Department, JobRole, MonthlyIncome, YearsAtCompany,
CASE WHEN Attrition = 'Yes' THEN 1 ELSE 0 END AS Attrition_Flag,
CASE WHEN OverTime = 'Yes' THEN 1 ELSE 0 END AS OverTime_Flag
FROM hr_employee_attrition;

这层薄薄的架构让下游的百分比计算快很多。

第三步：SQL分层定位流失热点

用聚合查询锁定离职到底发生在哪些部门、哪些薪资段：

SELECT Department, COUNT(*) as Total_Employees,
ROUND(AVG(Attrition_Flag)*100, 2) as Attrition_Rate
FROM vw_hr_attrition_clean
GROUP BY Department
ORDER BY Attrition_Rate DESC;

这一步的输出直接决定了看板上的第一屏该放什么指标。

第四步：Power BI直连与DAX建模

没用静态导出，而是让Power BI以Import Mode直连本地MySQL。为了保持DAX架构整洁，我建了专门的度量值矩阵表，显式写KPI，不靠默认列汇总：

Total Employees = COUNT(vw_hr_attrition_clean[EmployeeNumber])
Total Attrition = SUM(vw_hr_attrition_clean[Attrition_Flag])
Attrition Rate = DIVIDE([Total Attrition], [Total Employees], 0)

三个度量值撑起了整个看板的核心数字。

第五步：从数字到行动

数据没有业务上下文就是噪音。基于看板交互，我筛出三个高优先级" flight risk "信号，并配了对应的HR动作：

1. 加班是明牌：长期加班员工的离职率高达30.6%，是不加班群体的3倍。建议：对连续三个月加班超40小时的员工触发经理谈话。

2. 薪资倒挂检测：同职级、同年资员工中，收入处于底部20%的人群流失风险显著偏高。建议：季度薪酬回顾时优先覆盖这部分人。

3. 司龄拐点：入职第2-3年是离职高峰，之后曲线平缓。建议：针对满2年员工设计保留激励包。

这套流程的关键在于：所有清洗逻辑下沉到数据库视图，Power BI只负责计算和呈现。这样当数据量从1470行膨胀到147万行时，架构不需要重写。

最后留一个可复用的检查清单：主键去重做了吗？零方差列删了吗？文本字段转数值了吗？度量值显式定义了吗？业务洞察对应到具体行动了吗？五步全走完，才算一个闭环的数据项目。