Spring Boot应用：数据库与服务层时间戳转换方案对比咨询

架构老林

2026-6-23

数据库时间转换 vs 服务层时间转换：性能与代码分离对比

问题描述

在Spring Boot应用中，时间值以long类型存储。查询多条数据时，我在JPQL中通过DATE_FORMAT和FROM_UNIXTIME转换时间，代码如下：

@Query("SELECT new today.feeling.dto.response.emotion.EmotionMonthlyReportQuery(" +
        "s.id, " +
        "s.studentId, " +
        "s.name, " +
        "CAST(DATE_FORMAT(FROM_UNIXTIME(e.emotionTime / 1000, '%Y-%m-%d %H:%i:%s'), '%Y-%m-%d') AS string) AS emotion_date, " +
        "CAST(SUM(CASE WHEN e.emotionType = 1 THEN e.emotionLevel ELSE 0 END) / COUNT(CASE WHEN e.emotionType = 1 THEN 1 END) AS FLOAT), " +
        "CAST(SUM(CASE WHEN e.emotionType = 2 THEN  e.emotionLevel ELSE 0 END) / COUNT(CASE WHEN e.emotionType = 2 THEN 1 END) AS FLOAT), " +
        "CAST(SUM(CASE WHEN e.emotionType = 3 THEN e.emotionLevel ELSE 0 END) / COUNT(CASE WHEN e.emotionType = 3 THEN 1 END) AS FLOAT), " +
        "CAST(SUM(CASE WHEN e.emotionType = 4 THEN e.emotionLevel ELSE 0 END) / COUNT(CASE WHEN e.emotionType = 4 THEN 1 END) AS FLOAT)) " +
        "FROM Emotion e " +
        "JOIN Student s ON s.id = e.student.id " +
        "WHERE s.isRemoved = FALSE AND s.classroom.id = :classroomId AND s.year = :year AND e.emotionTime BETWEEN :startDate AND :endDate " +
        "GROUP BY s.id, emotion_date " +
        "ORDER BY s.studentId, emotion_date")
List<EmotionMonthlyReportQuery> getEmotionMonthlyReportList(@Param("classroomId") Long classroomId,
                                                           @Param("year") Integer year,
                                                           @Param("startDate") long startDate,
                                                           @Param("endDate") long endDate);

想请教：直接在数据库中转换时间，还是在服务层转换更好？哪种方案在性能或代码分离方面更优？

补充信息

数据库表结构

student表

CREATE TABLE `student` (
  `number` int NOT NULL,
  `year` int NOT NULL,
  `classroom_id` bigint DEFAULT NULL,
  `created_at` bigint NOT NULL,
  `grade_id` bigint DEFAULT NULL,
  `id` bigint NOT NULL AUTO_INCREMENT,
  `updated_at` bigint NOT NULL,
  `name` varchar(255) NOT NULL,
  `password` varchar(255) NOT NULL,
  `raw_password` varchar(255) NOT NULL,
  `role` varchar(255) NOT NULL,
  `student_id` varchar(255) DEFAULT NULL,
  `is_removed` tinyint NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `UK_lh7am6sc9pv0nhyg7qkj7w5d3` (`student_id`),
  KEY `FK1rs4md9whkjqy20v181d18kfy` (`classroom_id`),
  KEY `FK4xvaqcll34afqdd9vkydid5qo` (`grade_id`),
  CONSTRAINT `FK1rs4md9whkjqy20v181d18kfy` FOREIGN KEY (`classroom_id`) REFERENCES `classroom` (`id`),
  CONSTRAINT `FK4xvaqcll34afqdd9vkydid5qo` FOREIGN KEY (`grade_id`) REFERENCES `grade` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=68 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

emotion表

CREATE TABLE `emotion` (
  `emotion_level` int DEFAULT NULL,
  `emotion_shift` int DEFAULT NULL,
  `emotion_type` int NOT NULL,
  `emotion_time` bigint NOT NULL,
  `id` bigint NOT NULL AUTO_INCREMENT,
  `student_id` bigint NOT NULL,
  `emotion_image` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `FKp9g47t4p9sq8jrndlxa4m0igt` (`student_id`),
  CONSTRAINT `FKp9g47t4p9sq8jrndlxa4m0igt` FOREIGN KEY (`student_id`) REFERENCES `student` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=160 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

执行计划信息

执行计划显示：

对emotion表使用了FKp9g47t4p9sq8jrndlxa4m0igt外键索引，查询类型为ref，预计扫描行数为1
对student表使用了主键索引，查询类型为const，预计扫描行数为1
整体执行类型为SIMPLE，额外信息显示Using where; Using temporary; Using filesort

方案对比与建议

1. 性能维度

数据库转换

核心优势：
你的查询是分组聚合报表，数据库天生擅长批量数据处理。在数据库层面完成时间转换+分组+聚合，只需返回最终的聚合结果，避免了将大量原始emotion记录传输到服务层，网络和内存开销会小很多，数据量越大优势越明显。
优化点：
时间转换写法可以简化：CAST(DATE_FORMAT(FROM_UNIXTIME(e.emotionTime / 1000), '%Y-%m-%d') AS string)，去掉多余的中间格式定义，减少数据库计算步骤。
建议给emotion表的emotion_time字段加索引，当前BETWEEN条件依赖该字段，数据量增大后能显著提升查询效率。

服务层转换

核心劣势：
必须先拉取所有符合条件的原始emotion数据到服务层，再手动做时间转换、分组、聚合计算。数据量稍大时，网络传输和内存占用会急剧上升，性能远不如数据库端处理，而且手动实现聚合逻辑容易出错，维护成本高。
唯一优势：时间转换逻辑集中在服务层，后续修改格式无需改动JPQL。

2. 代码分离维度

数据库转换：时间转换和聚合逻辑绑定在JPQL中，属于数据层职责，符合数据层处理数据格式化与聚合的分工，但格式调整需要修改查询语句，耦合度较高。
服务层转换：时间转换属于业务逻辑层职责，和数据层解耦，代码结构更清晰，格式调整只需修改服务层代码，灵活性更强。

最终建议

结合你的聚合报表场景，优先选择在数据库层面完成时间转换和聚合计算：

数据库处理批量聚合的性能优势是服务层无法替代的，尤其是数据量增长后，差距会非常明显。
按照优化点简化JPQL中的时间转换写法，同时给emotion_time添加索引，进一步提升查询效率。

如果后续需要灵活调整日期格式，可以折中处理：让数据库返回原始long时间和聚合结果，服务层仅做时间转换——这样既保留了数据库聚合的性能优势，又能在服务层灵活调整格式。

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

Spring Boot应用：数据库与服务层时间戳转换方案对比咨询

问题描述 #

补充信息 #

数据库表结构 #