MySQL存储邻接矩阵场景下Spring Data JPA使用方案咨询

API 探路者

2026-9-29

核心结论

你当前的存储设计本身不符合关系型数据库范式，也不适配JPA的实体映射逻辑，不需要强行创建上百个属性的实体类，可按以下方案落地：

一、优先调整数据库存储结构（推荐方案）

你当前用宽表存储邻接矩阵的方式扩展性极差，新增站点就要加列，完全不适合后续维护，建议拆为邻接表结构：

新表仅需3个字段：from_station_id（起始站点ID）、to_station_id（目标站点ID）、is_connected（连通标识，tinyint类型存0/1）
对应的JPA实体仅需3个属性，符合常规开发规范，示例代码如下：

@Entity
@Table(name = "station_connect")
public class StationConnect {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private Long fromStationId;
    private Long toStationId;
    private Boolean isConnected;
    // 省略get/set方法
}

读取时直接查询全表数据，转换为内存数据结构即可，后续新增站点仅需新增行数据，无需修改表结构。

二、不修改现有表结构的适配方案

如果暂时无法调整表结构，可跳过JPA实体映射，用原生查询的方式读取数据：

直接使用JdbcTemplate执行SELECT * FROM stations原生SQL，返回结果为List<Map<String, Object>>，每一条Map对应一行数据，Key为列名（即目标站点标识），Value为0/1连通值
无需定义任何包含全字段的实体类，灵活度更高。

三、内存数据结构选择（适配BFS等图算法）

建议最终在内存中存储邻接表结构，相比二维数组空间占用更低、遍历效率更高：

若站点ID为连续整数，可使用List<List<Integer>>，下标对应起始站点ID，List存储所有连通的目标站点ID，只存储连通值为1的站点，忽略0值
若站点ID不连续，可使用Map<Long, List<Long>>，Key为起始站点ID，Value为连通站点列表
以上两种结构都可以直接适配BFS、DFS、最短路径等常用图算法。