fix: 修正定时任务调度时间与计划选取逻辑，每天凌晨 1 点执行

aucma-base/src/main/resources/梳理.md

@@ -0,0 +1,63 @@
+面对一堆表、触发器和代码，刚开始觉得无从下手是非常正常的。别担心，这个系统的本质其实就是一个**“数据加工厂”**。
+
+我们不看枯燥的代码，直接从宏观视角，一步步把这个加工厂的“四层流水线”盘明白！
+
+第一步：为什么要搞这么复杂？（背景与痛点）
+以前查产量可能很简单，但现在设备多了，遇到了几个大麻烦：
+
+机器不听话： 设备的计数器有时候会莫名其妙被清零，或者跨天了却没有清零，导致产量算不准。
+
+大屏扛不住： Board4 是一个高频刷新的大屏，如果每次刷新都去海量的原始数据里现算产量，数据库压力会非常大，甚至卡死。
+
+为了解决这些问题，系统把数据分成了四个层级（四张表）来处理。
+
+第二步：四大核心“仓库”（系统架构）
+整个业务流程就是数据在这四个仓库里流转的过程：
+
+人工录入层 (BASE_DEVICE_PARAM_VAL)： 这是给 5 台无法自动采集的“老设备”（OLD设备）准备的，工人用 PDA 扫码录入的数据存这里。
+
+自动采集层 (BASE_DEVICE_PARAM_VAL_YYYYMM)： 这是给新设备准备的，因为数据量太大，所以按月建表（比如3月份就是202603表）。特别注意：现在每个月新建这张表的活儿，交给了 C# 采集程序来负责。
+
+实时累计层 (RT_DAILY_PROD_STATE)： 这是一个“今日计分板”，只存每台设备今天产了多少。
+
+日汇总层 (DEVICE_DAILY_PRODUCTION)： 这是一个“历史档案馆”，保存过去每一天最终算好的权威总产量。
+
+第三步：数据是怎么进来的？（采集与实时计算）
+系统里有两种设备，它们的“计分”方式不一样：
+
+老设备（PDA人工录入）：
+
+工人用 PDA 录入数据存入“人工录入层”单表。
+
+后端的 Java 程序在写入成功后，会立刻同步更新“今日计分板”（RT表）。
+
+新设备（自动采集）：
+
+C# 程序把数据不断塞进当月的“自动采集层”分表里。
+
+数据库里装了一个触发器（比如 TRG_BDPV_202603_RT）。只要分表里一进新数据，触发器就会自动计算，并更新“今日计分板”（RT表）。
+
+💡 核心黑科技：怎么防止机器清零？（delta-sum 算法）
+触发器在算分时非常聪明。它统一看 机台状态-实际产出数量 这个参数：
+
+如果新数字比旧数字大，就把差值加到总产量里。
+
+如果新数字比旧数字小，说明机器清零了！此时直接把新数字当作新增的产量加进去，同时记录一次“重置次数”。
+
+第四步：到了晚上怎么办？（夜间搬运工）
+“今日计分板”（RT表）只管今天的事，到了明天怎么办？
+
+每天夜里 00:10，数据库会自动唤醒一个定时任务（JOB_FLUSH_RT_TO_DAY）。
+
+这个任务会把“今日计分板”里昨天的最终数据，打包搬运到“历史档案馆”（DAY表）中。
+
+搬运完后，清空“计分板”里的昨日数据，干干净净迎接新的一天。
+
+第五步：Board4 大屏最后怎么展示？
+经过前面的层层加工，大屏要查数据就变得非常轻松了：
+
+查今日总产量 / 查单台设备今日产量： 直接去“今日计分板”（RT表）里拿，速度极快。
+
+查本月总产量： 把“历史档案馆”（DAY表）里本月已经汇总的数据，加上“今日计分板”里今天的临时数据，两者一加就出来了。
+
+简单总结你的业务闭环：C#负责建表存明细 ➡️ 数据库触发器和Java负责算出今日实时产量 ➡️ 每天半夜存入历史档案库 ➡️ 大屏直接拿结果展示。