邻接矩阵 vs 邻接表：图存储的 2 种方案性能与适用场景对比

邻接矩阵 vs 邻接表：图存储的 2 种方案性能与适用场景对比

在算法设计与系统开发中，图的存储结构选择直接影响程序性能和资源消耗。邻接矩阵和邻接表作为两种最基础的存储方案，各自在空间效率、查询速度、动态操作等方面展现出截然不同的特性。本文将深入解析这两种结构的实现原理，并通过实际场景对比其优劣，最后给出不同业务场景下的选型建议。

1. 核心概念与实现原理

1.1 邻接矩阵的数学表达

邻接矩阵用二维数组表示顶点间的连接关系。对于包含n个顶点的图，矩阵大小为n×n：

• 无权图 ：矩阵元素A[i][j]=1表示顶点i到j存在边，反之为0
• 带权图 ：矩阵元素存储边的权重值，用特殊值（如∞）表示无连接

// C语言邻接矩阵结构体示例
#define MAX_VERTEX 100
typedef struct {
    int vertex[MAX_VERTEX];       // 顶点集合
    int matrix[MAX_VERTEX][MAX_VERTEX]; // 邻接矩阵
    int vertexNum, edgeNum;       // 顶点数和边数
} AdjMatrixGraph;

无向图特性 ：矩阵必然对称，主对角线通常为0（除非允许自环边）

1.2 邻接表的链式结构

邻接表将每个顶点的邻接点存储在链表中，典型实现包含两部分：

1. 顶点数组 ：保存顶点信息和指向邻接链表的指针
2. 边链表 ：存储相邻顶点索引和边属性

# Python邻接表实现示例
class AdjListNode:
    def __init__(self, dest, weight=0):
        self.dest = dest
        self.weight = weight
        self.next = None

class AdjListGraph:
    def __init__(self, vertex_count):
        self.vertex_count = vertex_count
        self.edges = [None] * vertex_count  # 邻接链表数组

空间优化 ：相比邻接矩阵的O(n²)，空间复杂度降至O(n+m)，其中m为边数

2. 关键性能指标对比

2.1 时间复杂度分析

*注：假定在链表头部插入边

2.2 空间占用实测

通过模拟不同规模图的存储消耗（单位：KB）：

测试环境：64位系统，int类型占4字节，指针占8字节

3. 典型应用场景解析

3.1 邻接矩阵优势场景

稠密图处理 ：当边数接近完全图时（如社交网络全连接关系），矩阵存储效率反而更高

// 社交关系强度分析示例（矩阵运算）
public double[][] calculateSocialImpact(double[][] adjacencyMatrix) {
    int n = adjacencyMatrix.length;
    double[][] impact = new double[n][n];
    // 矩阵幂运算计算三度影响力
    for (int k = 0; k < 3; k++) {
        impact = matrixMultiply(impact, adjacencyMatrix);
    }
    return impact;
}

快速查询需求 ：路由算法中需要频繁判断顶点连通性，矩阵的O(1)访问优势明显

3.2 邻接表优势场景

稀疏图存储 ：交通路网等稀疏场景下，实测存储消耗可降低2个数量级

# 地铁线路路径规划示例
def find_all_routes(graph, start):
    routes = []
    stack = [(start, [start])]
    while stack:
        (vertex, path) = stack.pop()
        neighbor_node = graph.edges[vertex]
        while neighbor_node:
            if neighbor_node.dest not in path:
                new_path = path + [neighbor_node.dest]
                stack.append((neighbor_node.dest, new_path))
                routes.append(new_path)
            neighbor_node = neighbor_node.next
    return routes

动态图处理 ：频繁增减顶点的场景（如实时推荐系统图），链表结构修改成本更低

4. 混合方案与优化技巧

4.1 稀疏矩阵压缩

对于部分稀疏的特殊矩阵，可采用以下优化：

1. CSR格式 ：压缩行存储，适合矩阵乘法
   • 非零值数组：存储有效边权重
   • 列索引数组：记录列坐标
   • 行指针数组：标记行起始位置

// CSR格式结构体示例
struct CSRGraph {
    vector<double> values;
    vector<int> col_indices;
    vector<int> row_ptr;
};

4.2 邻接表性能优化

1. 哈希邻接表 ：将链表替换为哈希表，查询效率提升至O(1)

   class HashAdjGraph:
       def __init__(self, vertex_count):
           self.vertex_count = vertex_count
           self.edges = [dict() for _ in range(vertex_count)]
   

2. 预分配数组 ：预估最大度数，用变长数组替代链表减少指针开销

4.3 决策树选择指南

根据业务需求选择存储结构的判断流程：

1. 是否图密度 > 40%？ → 选择邻接矩阵
2. 是否需要频繁修改顶点？ → 选择邻接表
3. 是否主要进行邻接查询？ → 选择邻接矩阵
4. 是否内存极度受限？ → 选择邻接表
5. 是否需要进行矩阵运算？ → 选择邻接矩阵

5. 真实系统中的应用差异

5.1 数据库索引设计

Neo4j等图数据库 ：普遍采用邻接表变种，支持：

• 属性图的灵活扩展
• 万亿级边的高效遍历
• 动态schema变更

矩阵数据库 ：如RedisGraph使用压缩矩阵，优势在于：

• 相似度计算加速
• 批量关系运算
• GPU加速支持

5.2 机器学习场景对比

实际在GNN实现中，通常会将邻接表转换为稀疏矩阵格式（如PyTorch Geometric的COO格式），兼顾效率和便利性。

在具体编码时，我曾遇到一个有趣案例：当用邻接矩阵处理百万级社交图时，即使使用稀疏矩阵存储，某些聚合操作仍会比邻接表实现慢3-5倍。这提醒我们理论复杂度与实际性能可能存在差异，关键操作的热点路径需要实际profiling。