Device 设备服务数据库设计

设备服务围绕三个业务问题组织数据：这台设备是谁、设备是否仍在使用、设备上安装了什么。设备认证与渠道归属以 MySQL 档案为基础；ES 提供设备及安装应用检索；TDengine 保存活跃、运行时长；Redis 承担身份查询缓存、心跳和活跃去重。规则筛选导出、日志文件登记和月活对比是后续增加的管理能力。

当前状态是微服务拆分尚未完成。 nebula_ids 是单体版遗留数据库，仍承载设备核心档案，也有 task 等服务仍在使用的对象。device 已有独立库 ik_yudao_device 和应用安装库 ik_app_install；task 也有自己的独立库，不能用“device 与 task 共用一个库”代替当前架构说明。对象在哪个库、由哪个服务访问，需要分别看数据源路由和源码。

阅读顺序

文档	回答的问题
设备档案、认证与渠道	设备如何识别、认证、分渠道，Excel 清单如何关联设备
活跃、运行时长与留存	活跃和开机时长有什么区别，统计口径如何落库
安装应用与检索	安装清单为什么按月存储，MySQL 和 ES 分别承担什么
大数据查询路径与使用边界	查哪个 ES 索引或 MySQL 月表、用哪些字段和分区、哪些优化已实现
规则导出与日志文件	新管理能力如何落到独立设备库，并关联 rule、infra、task
源码映射清单与结构差异	完整源码对象、继承字段、实库差异和后续核查点

数据源与边界

代码数据源别名	实际存储	业务边界
master	MySQL nebula_ids	遗留设备、渠道、型号、认证、MAC 分配、Excel 清单和型号统计；不是 device 专属库
deviceYudao	MySQL ik_yudao_device	日志文件、月活对比和规则导出的 5 张独立设备表
appInstall	MySQL ik_app_install	月度设备安装快照及按包名统计
tdDeviceActivity{Day/Month/Year} 及 Uota2/UotaOld/UotaNew 后缀	12 个 device_activity_* 库	默认、域名分发、新旧 UOTA 的日/月/年活跃口径
tdDeviceRuntime	TDengine device_runtime	开机运行明细；同库另有未被当前明细实体映射的 device_runtime 超级表
tdDeviceRuntimeCount{Day/Month/Year}、tdDeviceRuntimeCountDayShadow	4 个 device_runtime_count_* 库	日/月/年运行统计及日影子库；月、年影子路由未证实完整
Easy-ES	base_device、app_install_device{yyyyMM} 等	查询投影和全文检索，不代替 MySQL 档案的权威身份
Redis	缓存、集合、ZSET、锁	心跳、MAC/CPU 索引、活跃去重及任务互斥；本次未连接 Redis 采集

Mermaid Diagram Code:

flowchart LR
  Report[设备上报与认证] --> Service[device 服务]
  Service --> Legacy[遗留 MySQL nebula_ids]
  Service --> Own[独立 MySQL ik_yudao_device]
  Service --> Install[MySQL ik_app_install]
  Service --> TD[TDengine 活跃和运行时长]
  Legacy --> CDC[数据库变更消息]
  Install --> CDC
  CDC --> ES[ES 查询投影]
  CDC --> Redis[Redis 身份缓存]
  Service --> Redis
  Service --> Task[task 导出任务 API]
  Service --> Rule[rule 规则匹配]

证据与核验边界

核验日期：2026-09-18。数据源来自本次统一采集的 manifest.json.service_bindings.device，MySQL、TDengine、ES 为测试环境只读结构采集；业务流程来自当前源码静态分析，未启动服务、运行任务或扫描业务记录。采集成功只证明对象结构存在，不能证明同步及时、任务启用或历史数据完整。

完整物理字段、默认值、索引及约束见 遗留库字典、独立设备库字典、安装应用库字典。这些字典覆盖整库，包含本服务不拥有的对象；本服务归属以本目录源码清单为准。

本目录引用源码时，D/ 表示仓库根目录下 ik_project/yudao-cloud/yudao-module-device/yudao-module-device-biz/src/main/java/cn/iocoder/yudao/module/device/，R/ 表示同一 biz 模块的 src/main/resources/，F/ 表示 ik_project/yudao-cloud/yudao-framework/。引用末尾数字为当前源码行号。

设备档案、认证与渠道关系

设备档案不是单纯的 MAC 清单。管理端先导入或维护设备及渠道，设备端认证时再补充 CPU、固件、SDK、IP、激活信息；相同 MAC 可能出现不同 CPU，代码因此同时支持 MAC 查询和 MAC+CPU 精确匹配。业务变化使档案逐渐加入实际内存/闪存、生产订单、主板型号等字段，不能仅根据早期“型号、渠道、MAC”设计解释当前表。

身份与生命周期

nebula_ids.base_device 是主档案，id 是内部引用编号，mac + cpu 是实库唯一索引。MAC 单列查询有选择逻辑，不能宣称 MAC 在全库唯一。后台按条件修改渠道、导入清单、认证更新和物理删除均在 DeviceServiceImpl 中实现。status、certification 表示业务状态及认证信息；activation_time 表示首次激活，不等于本月活跃，也不等于最后在线时间。

activationTime 虽标注 insertStrategy/updateStrategy=NEVER，仍然是物理字段；特定 Mapper 方法负责写入。BasePhysicsDO 提供创建、更新人和时间及 deleted 字段，但没有 @TableLogic，不能把所有删除解释为逻辑删除。beginTime、endTime、channelName 标记 exist=false，属于查询/展示辅助，不是主表字段。

表	业务用途与关键字段	读写和约束
base_device	设备身份、渠道、型号、硬件/固件、激活时间和租户归属；real_ddr/real_flash 与上报 ddr 分开存放	管理端、认证逻辑写，其他业务查询；主键 id，唯一 (mac,cpu)，渠道、型号、激活/创建/更新时间索引
base_channel	渠道名称、公司归属、默认任务、描述和更新版本	渠道管理写、设备/任务读；describeInfo 为显式映射的实际列名
base_device_model	型号字典	管理端维护；设备 model_id 为逻辑引用，同时保留 device_model 文本
device_certification	认证过程记录，保留 MAC/CPU、固件、请求域名、SDK 和认证类型	认证服务记录；它是过程数据，不替代主档案认证状态
base_device_info_modify	为设备分配替换 MAC；allocated_mac 是候选地址，device_mac/cpu 是申请设备，status/allocated_time 标记分配进度	服务通过 Redis MAC 池取号后维护记录；allocated_mac 实测唯一
device_mac_type	特定类型 MAC 集合	DeviceMacTypeMapper.selectListByType 明确读取；实体注解与实际 SQL 不一致，详见差异页
sys_region	区域名称、ISO 名和简称	地区管理 Mapper 的显式 XML 访问；不因缺少 @TableName 就漏记
sys_app_package_name	包名描述、自定义应用名称、状态与删除标志	安装应用展示及包名管理共用；deleted 映射的是 del_flag

关联关系：物理约束与业务引用分开

Mermaid Diagram Code:

erDiagram
  base_channel ||--o{ base_device : "逻辑 channel_id"
  base_device_model ||--o{ base_device : "逻辑 model_id"
  sys_region ||--o{ base_device : "逻辑 region_id"
  base_task ||--o{ base_channel : "物理 FK task_id"
  device_excel_file ||--o{ device_excel_file_rel : "逻辑 excel_file_id"
  base_device ||--o{ device_excel_file_rel : "逻辑 device_id"

实测 base_channel.task_id → base_task.id 存在名称为 task 的物理外键，更新和删除规则均为 NO ACTION。其他图示设备关系是代码中的逻辑关联，没有采集到对应物理 FK。company_id/user_id 是遗留归属编号，不能在未核验迁移映射时直接等同于新 system 库同值主键。认证、活跃、安装快照还通过 MAC/CPU 与设备对应，数据库不替服务保证跨存储一致性。

Excel 清单的业务含义

Excel 功能用于保存一批设备的筛选集合。device_excel_file 保存名称、总行数、匹配数和状态，device_excel_file_rel 保存清单与已识别设备的多对多关系。实库唯一索引 uk_file_device(excel_file_id,device_id) 防止同一清单重复关联同一设备。

当前 matchDeviceIds 收集规范化 MAC 后通过 Redis→ES→DB 查设备 ID；虽然输入对象带 CPU，当前这段匹配采用 MAC 集合，应避免把文档写成“始终按 MAC+CPU 精确匹配”。关联同时投影到 ES base_device.excel_file_ids，追加时通过脚本判断已有值，删除清单时移除对应索引值。因此关系表与 ES 数组是两份不同用途的数据，需要分别维护。

ES 与 Redis 投影

DeviceMysqlChangeConsumer 消费数据库变更消息，更新 ES 和 Redis；查询装饰器按配置选择数据来源。base_device ES 的 id 使用文档 _id，channel_name/excel_file_ids 是额外查询投影字段，不能反推为 MySQL 主表列。Redis 还保存设备心跳 ZSET：成员采用 MAC+CPU，分数是最后在线时间；DeviceHeartDO.key/lastOnLineTime 是 Redis 对象，不是一张缺失的 MySQL 表。

这条链路说明为何“数据库表有字段”不代表“ES 查询立即可见”：同步开关、消费者进度、投影构造均影响最终展示。本次只核验结构和源码，没有核验消息积压或实际同步一致性。

源码证据

证据	位置
主档案映射和非落库字段	D/dal/dataobject/device/DeviceDO.java:15,82,161；R/mapper/device/DeviceMapper.xml:12
导入、认证、物理删除	D/service/device/DeviceServiceImpl.java:99,160,286,574
MAC 类型真实查询	D/dal/mysql/device/DeviceMacTypeMapper.java:17
Excel 匹配与 ES 投影	D/service/device/DeviceExcelFileServiceImpl.java:200,207
数据库变更同步	D/kafka/consumer/DeviceMysqlChangeConsumer.java:57,63,143
心跳 ZSET	D/dal/redis/device/DeviceHeartRedisDAO.java:25,31,38
MAC 分配池	D/service/deviceInfoModify/DeviceInfoModifyServiceImpl.java:154,169
地区显式映射	R/mapper/region/SysRegionMapper.xml:5,15

字段类型和全部索引见 nebula_ids 字典；ES mapping 见 base_device 字典。

设备规则导出与日志文件

随着设备管理从基础清单扩展到规则筛选、离线分析和故障排查，设备服务新增了独立库 ik_yudao_device。其 5 张实测表分别覆盖日志文件、月活结果和规则导出的配置/批次/记录。它们通过业务编号、文件 URL 和服务 API 与旧档案联动，并未把旧库所有设备数据整体迁入。

规则导出：配置、执行和结果分开保存

运营人员维护导出配置，再创建执行批次。执行器读取设备备份 SQL 文件，解析其 DDL 确定列位置，逐条构造设备对象调用规则匹配，按命中的配置输出文件。这里是业务功能原有的离线备份处理链路，不是本次文档采集采用的方式；本次未下载备份或执行业务导出。

配置表不直接保存整份规则表达式。执行器用 RuleRunUtil.matchBusinessIds 获取命中的业务编号，默认业务类型为 6，再与配置 ID 对应；规则定义由 rule 服务维护。选择特定配置 ID 时不额外限定启用状态，不指定时取启用配置，这是当前执行代码的实际规则。

表	为何独立存在	关键字段
device_rule_export_config	可重复使用的业务筛选配置	name/remark/status；规则服务以业务编号对应 id
device_rule_export_batch	一次执行的进度、日志及输入追踪	device_backup_url 记录输入备份，status/start_time/end_time/progress/log 记录执行过程，total_device_count/matched_device_count 记录处理规模
device_rule_export_record	一个批次按一个配置产生的导出文件	batch_id/config_id/config_name/export_time/file_url/device_count，配置名作为导出时快照保留

Mermaid Diagram Code:

erDiagram
  device_rule_export_batch ||--o{ device_rule_export_record : "逻辑 batch_id"
  device_rule_export_config ||--o{ device_rule_export_record : "逻辑 config_id"

独立设备库未采集到物理外键；record 的 batch_id 和 config_id 各有普通索引。关系维护由 Service 实现，例如删除配置会清理子记录，删除记录会调用文件删除能力。Redis 锁及续租用于防止同一导出任务并发执行，数据库状态和 Redis 运行状态并不是同一种记录。

普通设备/活跃/安装清单导出另外使用 task 的 ExportTaskApi 管理任务状态，不能把这些任务与本地 device_rule_export_batch 混成一个表模型。

设备日志：保存文件引用，不把日志字节放进 MySQL

设备上传日志时，Service 校验并规范化 MAC，将缺省 CPU ID 归一为空字符串，再上传文件、写登记表。device_log_file 保存设备标识、原始文件名、大小、访问 URL、存储路径、租户和审计字段。

file_path 是返回给使用方的访问地址，storage_path 是后续删除所需的存储定位，两者职责不同。上传逻辑直接使用 FileClient/FileStorageUtil，不写入 infra_file；因此不能把该表画成必须依赖 infra_file.id 的外键关系。上传失败及数据库回滚有文件清理补偿，数据库行和外部文件无法仅靠 SQL 事务自动保持一致。

DeviceLogFileDO 继承审计字段，但显式用 exist=false 覆盖 deleted；实库确实没有 deleted 列，文档不补造逻辑删除字段。设备对应关系为 MAC/CPU 的逻辑关系，日志记录没有 device_id，档案被删除并不意味着数据库自动级联删除日志文件。

独立库完整性与迁移含义

本次实测 ik_yudao_device 的 5 表与本服务对应表完全匹配；device_month_activity_stat 的业务解释见 活跃统计。规则配置、批次和记录实库均有 tenant_id，实体继承的 BaseDO 不包含此字段；应把它记录为“实库额外、可能由租户拦截器参与”的差异，而不能因为实体没有就宣称数据库不做租户隔离。

保留旧 nebula_ids 与新增独立库的并存关系，是了解当前演进状态的前提。本次没有制定或实施迁库、删表、重建索引方案；整理结果用于后续按实际业务判断迁移范围。

源码证据

证据	位置
三张规则表数据源	D/dal/mysql/ruleexportconfig/DeviceRuleExportConfigMapper.java:18；D/dal/mysql/ruleexportconfig/DeviceRuleExportRecordMapper.java:20；D/dal/mysql/ruleexportbatch/DeviceRuleExportBatchMapper.java:18
配置及记录删除关系	D/service/ruleexportconfig/DeviceRuleExportConfigServiceImpl.java:70,122
批次锁与异步执行	D/service/ruleexportbatch/DeviceRuleExportBatchServiceImpl.java:91,116
备份解析、规则匹配、结果记录	D/service/ruleexportbatch/DeviceRuleExportTaskExecutor.java:147,157,177,423,461
规则业务类型默认值	D/service/ruleexportbatch/DeviceRuleExportProperties.java:20
日志上传和独立数据源	D/service/devicelogfile/DeviceLogFileServiceImpl.java:47,73,107
日志实体非持久化字段	D/dal/dataobject/devicelogfile/DeviceLogFileDO.java:14,69

完整字段与索引：ik_yudao_device 物理字典。

源码映射清单与实际结构差异

核验日期：2026-09-18。本页覆盖 device/dal/dataobject 下全部 25 个 Java 对象：18 个 MySQL 注解实体、1 个通过 XML 映射的地区对象、3 个 TDengine 对象、2 个 ES 对象及 1 个 Redis 心跳对象。对象数不等于物理表数：有同表投影、动态月表和跨多个库复用的超级表结构。

MySQL 完整映射清单

字段清单使用实际列名风格；未特别标注时 Java 属性按驼峰转下划线。A 表示继承审计字段 create_time,update_time,creator,updater,deleted；P 表示 create_time,update_time,creator,updater。BaseDO 的 deleted 有逻辑删除注解，BasePhysicsDO 的同名字段没有该注解。静态常量、序列化版本、exist=false 及翻译扩展 transMap 不列为落库字段。

源码位置均相对于首页定义的 D/；下表实体统一位于 dal/dataobject/。完整列类型、长度、默认值和索引以 catalog 为准，此处负责解释源码覆盖边界。

实体源码位置	数据源与表	全部映射字段
device/DeviceDO.java:15	master：base_device	id,mac,status,certification,user_id,company_id,channel_id,device_model,model_id,order_number,sdk_version_name,remarks,activation_time,name,brand,system_version,build,ddr,cpu,device_ip,region_id,ip_address,ui,serial_number,real_ddr,real_flash,production_order,master_model,pcb_model,tenant_id + A
channel/ChannelDO.java:15	master：base_channel	id,name,company_id,update_version,describeInfo,create_user,remarks,task_id + A
devicemodel/DeviceModelDO.java:19	master：base_device_model	id,name,create_time,update_time
device/DeviceCertification.java:20	master：device_certification	id,mac,cpu,system_version,build,ddr,device_ip,ip_address,type,request_host,sdk_version_name,create_time
deviceInfoModify/DeviceInfoModifyDO.java:19	master：base_device_info_modify	id,allocated_mac,device_mac,cpu,status,allocated_time + P
device/DeviceMacTypeDO.java:12	注解：base_device；实际自定义查询：device_mac_type	id,mac,type；注解目标缺 type，自定义查询只返回 mac
device/DeviceExcelFileDO.java:18	master：device_excel_file	id,name,total_rows,matched_count,status,create_time,update_time
device/DeviceExcelFileRelDO.java:19	master：device_excel_file_rel	id,excel_file_id,device_id,create_time
region/SysRegion.java:18	master：XML 显式访问 sys_region	id,name,iso_name,short_name
apppackage/AppPackageNameDO.java:14	master：sys_app_package_name	id,package_name,describe,status,del_flag,create_time,update_time,customize_app_name；Java deleted→del_flag
modelactivitydetail/DeviceModelActivityDetailDO.java:15	master：device_model_activity_detail	id,base_day,source_type,device_model,device_count,new_active_count,dead_count
devicelogfile/DeviceLogFileDO.java:14	deviceYudao：device_log_file	id,mac,cpuid,file_path,storage_path,file_name,file_size,tenant_id + P；覆盖排除继承 deleted
monthactivitystat/DeviceMonthActivityStatDO.java:16	deviceYudao：device_month_activity_stat	id,data_source,bench_month,bench_active_num,bench_new_act_num,cmp_offset,cmp_month,cmp_active_num,cmp_new_act_num,new_active_num,bench_resurrect_num,bench_loss_num,loss_reactive_num,both_active_num,new_act_both_active_num,cum_new_act_num,cum_loss_num,cum_new_active_num
ruleexportconfig/DeviceRuleExportConfigDO.java:15	deviceYudao：device_rule_export_config	id,name,remark,status + A
ruleexportbatch/DeviceRuleExportBatchDO.java:17	deviceYudao：device_rule_export_batch	id,name,status,start_time,end_time,log,progress,device_backup_url,total_device_count,matched_device_count + A
ruleexportconfig/DeviceRuleExportRecordDO.java:16	deviceYudao：device_rule_export_record	id,batch_id,config_id,config_name,export_time,file_url,device_count + A
appinstalldevice/AppInstallDeviceDO.java:23	appInstall：app_install_device{yyyyMM}	id,mac,cpu_id,last_undate_Time,app_count,create_time,update_time,apps,partition_index
appinstallpackage/AppInstallPackageDO.java:16	appInstall：app_install_package{yyyyMM}，兼有无后缀 SQL	id,package_name,mac,cpu_id,app_name,class_name,version_name,version_code,is_syste_app,last_undate_time,create_time,update_time,partition_index；实库系列未发现，列名是代码预期
appinstallpackage/AppInstallCountPackageDO.java:18	appInstall：app_install_count_package	id,app_name,package_name,class_name,month,version_name,version_code,device_count,create_time

DeviceDO 排除 beginTime/endTime/channelName，但 activationTime 只是禁止通用写入，仍参与查询和特定更新。DeviceLogFileDO.deleted 已排除，与实库一致。ChannelDO.describeInfo 显式使用同名列，不能机械改成 describe_info。

数据源证据：D/constant/DataSourceConstants.java:13；五个独立库 Mapper 的 @DS(DEVICE_YUDAO)；三个安装 Mapper 的 @DS(APP_INSTALL)。没有显式切换的上述 MySQL Mapper 使用当前服务 master。继承证据：F/yudao-spring-boot-starter-mybatis/src/main/java/cn/iocoder/yudao/framework/mybatis/core/dataobject/BaseDO.java:24、BasePhysicsDO.java:29。

TDengine、ES 与 Redis 完整对象

源码对象与位置	映射范围	全部字段及特殊规则
deviceActivityDetail/DeviceActivityDetailDO.java:19	12 个活跃库的 device_activity_detail	ts,data_key,mac,cpu,ip,device_id,sdk_version；TAG record_time,region_id；伪列 tbname
deviceRuntime/DeviceRuntimeDetailDO.java:22	device_runtime.device_runtime_detail	start_time,end_time,device_duration；TAG mac,cpu；伪列 tbname
deviceRuntime/DeviceRuntimeCountDO.java:18	主日/月/年及日影子库的 device_runtime_count	ts,data_key,mac,cpu,device_duration；TAG record_time；tbname 为伪列，tableName 不落库
device/DeviceEsEntity.java:29	ES base_device	_id 对应 id；正文见下方字段清单
appinstalldevice/AppInstallDeviceEs.java:24	ES app_install_device 逻辑索引与月索引	_id 对应 id；mac,cpu_id,last_undate_time,app_count,create_time,update_time,apps
device/DeviceHeartDO.java:18	Redis 心跳 ZSET	key,lastOnLineTime；不是 MySQL/TDengine 表

DeviceEsEntity 全部 _source 字段：mac,status,certification,user_id,company_id,channel_id,channel_name,device_model,model_id,order_number,sdk_version_name,create_time,update_time,remarks,activation_time,name,brand,system_version,build,ddr,cpu,excel_file_ids,device_ip,region_id,ip_address,ui,serial_number,real_ddr,real_flash,production_order,master_model,pcb_model,deleted。注释掉的 platform/params 不计入。两个 ES 实体的 id 为 @IndexId，mapping properties 不出现 id 不属于缺列。

活跃 Mapper 全部继承 BaseDeviceActivityMapper，通过 Day/Month/Year × 默认/Uota2/UotaOld/UotaNew 的 12 个具体 Mapper 选择数据源；运行时长为 Detail、CountDay/Month/Year、CountDayShadow 五个有效绑定。CountMonthShadow、CountYearShadow 虽有 Java 接口但 @DS 被注释，不能作为两个已核验库计算。

源码与实库对照结论

编号	发现	业务影响与解释边界
DEV-01	DeviceMacTypeDO 注解指向 base_device，其 type 在该表不存在；自定义 SQL 指向结构匹配的 device_mac_type	已核验注解与 SQL 不一致。自定义查询不等于通用 CRUD 安全；本次未修改代码或调用该路径
DEV-02	ik_app_install 无 app_install_package 及其月表，只有 count 表和 4 个月设备快照	包名展开/统计源码存在，当前结构没有该中间层；需确认调度状态和创建时机，不能凭旧 nebula_ids 同名表认定路由正确
DEV-03	base_channel、三张 rule_export 表实库多 tenant_id；base_device_info_modify 多 deleted,tenant_id	都是真实列，未在对应实体直接映射。租户拦截器可能参与 SQL，不能因此建议删除列
DEV-04	app_install_device 实际为年月表；last_undate_Time 列大小写与下划线转换结果不同	属于动态表和历史命名，不能误报未加后缀表不存在即业务必错；MySQL 列大小写差异不作为缺列
DEV-05	ES base_device.real_ddr/real_flash/production_order/master_model/pcb_model 源码声明 KEYWORD，实测为 text（具体子字段见字典）	精确匹配、排序、聚合应按实际 mapping 选择字段，源码注解不自动证明存量索引已变更
DEV-06	安装 ES 202601 驼峰/下划线字段并存；202602–202609 的日期和 CPU 类型与较早月份不同	反映索引演进差异，跨月检索不能假设同构；未扫描文档，无法判断旧/新字段填充比例
DEV-07	月、年影子 Mapper 的 @DS 已注释且本次配置未绑定	路由类具备影子分支不等于完整部署；仅确认日影子库，未切换或运行重构
DEV-08	device_runtime 库额外有同名 device_runtime 超级表，当前明细实体映射 device_runtime_detail	可能为演进遗留或其他写入端使用；没有访问证据时保留待确认，不能直接清理
DEV-09	安装 ES 有 19 个月索引，MySQL 只有 4 个月快照	说明物理保留范围不同，不证明其中任何一端数据缺失；无后缀及 _s0 的用途待确认
DEV-10	安装统计 XML 显式写死 ik_app_install 与 nebula_ids 跨库查询	数据源已拆分不等于 SQL 已解耦；后续迁库要连同包名说明查询一起评估，证据 R/mapper/appinstallpackage/AppInstallCountPackageMapper.xml:19,23

在本次字段名对照范围内，除上表外，所有已存在 MySQL 目标表的映射字段均找到对应列。TDengine 三个 DO 的普通列和 TAG 均找到对应结构；tbname、exist=false 已排除缺字段比较。Java Long 和 TDengine INT 并不表示同样的数值边界，完整物理类型仍应以 catalog 为准。本次未验证 ORM 运行转换、索引使用效果或数据值合法性。

实库额外对象与归属

ik_yudao_device 五张表已全部归属本服务；ik_app_install 五张表均已归属动态设备快照或 count 对象。nebula_ids 是整库共享的单体遗留现场，task、launcher 等对象由对应服务章节解释，不能整体记为 device 所有。

其中 device_activity_detail/device_runtime 的 MySQL 同名表、旧 app_install_device/app_install_package/app_install_count_package、app_install_device_detail/device_app_install_detail、flow_device_activity/flow_device_activity_202305/flow_device_activity_count/flow_device_activations_number、temp_device_activity/temp_mac/sys_app_package_name_temp 等在物理库仍存在，但本页当前 DO 主路由没有将这些对象作为对应新功能的现行目标。它们保留在完整遗留库字典，归为历史对象或其他路径待确认；仅凭前缀和名称不下“可删表”结论。

复核与维护方式

后续业务增加字段、变更统计口径或迁移数据源时，应一起更新业务页、映射清单和采集字典：先确认谁写谁读，再确认实体与实际结构，最后记录仍未迁移的调用方。MySQL 表名相同、ES 字段名相似、TDengine 库名后缀相近都不足以证明相同业务口径。

本次仅做源码静态核对及统一采集结果读取，不运行编译、测试、服务、Kafka 消费者、统计任务、ES 重建或数据库 DDL/DML。