feat(V2): 更新V2最新版本到20260625, 修复ffmpeg外部调用报错, 内存文件占满10GB的问题

[xiaorongnie]

• 修复ffmpeg外部调用报错, 内存文件占满10GB的问题, (ulimits)
• 更新V2最新版本到20260625

[jss-tg]

其他容器要不要加这个参数？

[xiaorongnie]

分析用户的请求：

用户提供了容器根目录（ls -lh）的输出。

输出显示大量名为 core.<数字> 的文件（例如 core.259、core.266 等），总计看起来有好几个 GB（注意 ls -lh 输出的总大小为 total 9.5G，文件列表主要是这些 core 文件）。

用户询问：“这个是什么文件，是转码遗留的吗”（这些是什么文件，是转码遗留的吗？）。

检查提供的证据：

total 9.5G —— 几乎所有空间都被这些文件占用。

文件名：core.259、core.266... core.9820。

文件大小：大多为 104M，一些是 26M、23M、4.8M、1.4M、2.8M。

权限：-rw-------（仅 root 可读写）。

日期：主要是 Jun 12，少数为 Jun 16、Jun 19、Jun 24。

路径：位于容器文件系统的根目录 /。

识别文件类型：

在 Linux 中，名为 core 或 core. 的文件是核心转储（core dumps）。

当程序崩溃（如段错误 Segmentation Fault）时，操作系统会将进程的内存映像写入此文件，用于事后调试。

它们不是转码（ffmpeg）遗留的正常视频文件。它们是崩溃内存转储。

回答用户的具体问题：

“这个是什么文件？” -> 核心转储文件（Core dump files）。由程序崩溃（段错误）生成。

“是转码遗留的吗？” -> 不是直接的视频转码输出文件。但是，如果你的 Java 进程因 JNI 调用（如通过 ffmpeg）而崩溃，或者 Java 自身崩溃，它就会生成这些。鉴于你提到了 ffmpeg 和视频，这很可能是 Java 应用程序在处理视频时崩溃，导致 JVM 或底层本地进程崩溃，从而转储了这些 core 文件。

找出根本原因（为什么生成这么多）：

显然，该应用程序反复崩溃（查看日期：大量在 6月12日，一些在之后）。这产生了大量 104MB 的文件。

Java 通常默认禁用核心转储或将其重定向，但容器内的 ulimit -c unlimited 可能已设置，或者 JVM 配置了 -XX:ErrorFile，但这些通常命名为 hs_err_pid.log。然而，位于 / 下的 core. 是标准的操作系统核心转储。

它们不是“转码遗留文件”（如 MP4），而是内存转储。

制定可操作的建议：

立即清理：rm -f /core.*（因为用户已经 root 登录）。这将立即释放近 10GB 的空间，解决磁盘满的问题。

防止复发：需要禁用核心转储生成，防止它在修复崩溃之前再次填满磁盘。

在容器内：ulimit -c 0（但这仅在会话内有效）。

永久修复：在 docker-compose.yml 中，添加 ulimits 配置 core: 0，或者在启动命令中设置 ulimit -c unlimited（显然是错误的，当前设为 unlimited）。实际上，在 compose 的 ulimits 部分，他们已经设置了 nproc 和 nofile，但没有设置 core。他们需要明确将 core 大小设为 0。

或者，在容器启动脚本中设置 ulimit -c 0。

根本原因分析：程序为什么崩溃？（可能是段错误，可能是 ffmpeg 处理问题）。检查 dmesg（如果可用）或 Java 日志中的 hs_err_pid 文件，但首要任务是清理空间并停止新 core 文件的生成。

[xiaorongnie]

Code Review 结果（Claude Code /review）

针对本次 PR 中 mysql8/initdb/01-maintain-init-table.sql 的变更进行 review，发现以下 4 个问题（按严重程度排序）：

1. ledger_employee_attendance 表注释错误

• 位置：mysql8/initdb/01-maintain-init-table.sql:1113
• 问题：新表 ledger_employee_attendance 的表注释使用了 '时间点的行程分析'，这与 ledger_trip_index 的注释完全相同，但前者是员工刷卡考勤表（boarding_type、swipe_time、emp_id 等字段），语义不符。
• 影响：DBA/开发者从 SHOW TABLE STATUS 或 information_schema 查看时会误解表用途。
• 建议：将注释改为 '员工刷卡考勤记录' 或类似描述。

2. organize_service_route 排序规则与其他表不一致

• 位置：mysql8/initdb/01-maintain-init-table.sql:2788
• 问题：该表（含所有列）使用了 utf8mb4_0900_ai_ci，而文件中其他表均使用 utf8mb4_general_ci。
• 影响：与 organize_info 等表通过 organize_id 等字段 JOIN 时，可能因排序规则不匹配导致隐式转换、索引失效或比较行为不一致。
• 建议：统一改为 utf8mb4_general_ci，与仓库内其他表保持一致。

3. view_organize_user 派生表别名与视图名相同

• 位置：mysql8/initdb/01-maintain-init-table.sql:3844
• 问题：视图定义中 from (...) view_organize_user 将派生表别名命名为与视图本身相同的名字，形成自引用/名称遮蔽，可读性差且脆弱。
• 影响：后续维护容易混淆，存在误改风险。
• 建议：将别名改为 derived 或 t 等中性名称。

4. organize_vehicle.active 注释存在重复值

• 位置：mysql8/initdb/01-maintain-init-table.sql:2873
• 问题：注释 '0表活动，1表等待(3 个月)，1表等待(6 个月), 3表过期，4表过期， 5表取消，6表暂停' 中，值 1 被同时用于“等待 3 个月”和“等待 6 个月”两个不同状态。
• 影响：开发者无法判断 active = 1 的确切含义，可能导致业务逻辑判断错误。
• 建议：修正注释，将两个等待状态分别对应到不同的枚举值（例如 1 和 2）。

---

已排除的误报：

• view_user_organize LEFT JOIN organize_fleet 不会产生重复行，因为 organize_fleet 在 (organize_id, fleet_id) 上有唯一索引。

自动化校验：node scripts/check-init-sql.js 已通过，未发现 INSERT 列数不匹配。

[xiaorongnie]

重新 Review 结果（修复后）

针对 commit 127d209 fix: 修复review 进行重新 review：

已确认修复 ✅

#	原问题	修复位置	状态
1	ledger_employee_attendance 表注释错误	mysql8/initdb/01-maintain-init-table.sql:1113	✅ 已改为 '员工刷卡考勤记录'
2	organize_service_route 排序规则不一致	mysql8/initdb/01-maintain-init-table.sql:2788	✅ 已统一为 utf8mb4_general_ci
3	organize_vehicle.active 注释重复值	mysql8/initdb/01-maintain-init-table.sql:2873	✅ 已改为 1=等待(3个月), 2=等待(6个月)

仍未修复 ⚠️

#	问题	位置	说明
4	view_organize_user 派生表别名与视图名相同	mysql8/initdb/01-maintain-init-table.sql:3844	from (...) view_organize_user 仍使用视图名作为派生表别名，建议改为 derived 或 t 等中性名称

新增问题

未发现。

自动化校验

node scripts/check-init-sql.js 已通过，未发现 INSERT 列数不匹配。

---

结论：3/4 个问题已修复，剩余 1 个为命名清晰度问题，不影响功能但建议顺手改掉。

[xiaorongnie]

其他容器要不要加这个参数？

不需要，现在只有这个调用了外部程序