另一個MySQL DBA: MySQL + Neo4j 用于 AI 工作负载：为什么关系型数据库仍然重要

所以我想是时候记录一下如何使用你已经熟悉的数据库为 AI 代理构建持久内存了。不是向量数据库 - 而是 MySQL 和 Neo4j。

这不是理论。我每天都在使用这种架构，在多个项目中处理 AI 代理内存。这是真正有效的 schema 和查询模式。

架构

AI 代理需要两种类型的内存：

结构化内存 - 发生了什么、何时、为什么 (MySQL)
模式内存 - 什么与什么相连 (Neo4j)

向量数据库适用于相似性搜索。它们不适合跟踪工作流状态或决策历史。为此，你需要 ACID 事务和正确的关系。

MySQL Schema

这是 AI 代理持久内存的实际 schema：

-- Architecture decisions the AI made
CREATE TABLE architecture_decisions (
    id INT AUTO_INCREMENT PRIMARY KEY,
    project_id INT NOT NULL,
    title VARCHAR(255) NOT NULL,
    decision TEXT NOT NULL,
    rationale TEXT,
    alternatives_considered TEXT,
    status ENUM('accepted', 'rejected', 'pending') DEFAULT 'accepted',
    decided_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    tags JSON,
    INDEX idx_project_date (project_id, decided_at),
    INDEX idx_status (status)
) ENGINE=InnoDB;

-- Code patterns the AI learned
CREATE TABLE code_patterns (
    id INT AUTO_INCREMENT PRIMARY KEY,
    project_id INT NOT NULL,
    category VARCHAR(50) NOT NULL,
    name VARCHAR(255) NOT NULL,
    description TEXT,
    code_example TEXT,
    language VARCHAR(50),
    confidence_score FLOAT DEFAULT 0.5,
    usage_count INT DEFAULT 0,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    updated_at DATETIME ON UPDATE CURRENT_TIMESTAMP,
    INDEX idx_project_category (project_id, category),
    INDEX idx_confidence (confidence_score)
) ENGINE=InnoDB;

-- Work session tracking
CREATE TABLE work_sessions (
    id INT AUTO_INCREMENT PRIMARY KEY,
    session_id VARCHAR(255) UNIQUE NOT NULL,
    project_id INT NOT NULL,
    started_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    ended_at DATETIME,
    summary TEXT,
    context JSON,
    INDEX idx_project_session (project_id, started_at)
) ENGINE=InnoDB;

-- Pitfalls to avoid (learned from mistakes)
CREATE TABLE pitfalls (
    id INT AUTO_INCREMENT PRIMARY KEY,
    project_id INT NOT NULL,
    category VARCHAR(50),
    title VARCHAR(255) NOT NULL,
    description TEXT,
    how_to_avoid TEXT,
    severity ENUM('critical', 'high', 'medium', 'low'),
    encountered_count INT DEFAULT 1,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    INDEX idx_project_severity (project_id, severity)
) ENGINE=InnoDB;

外键。检查约束。正确的索引。这是关系型数据库擅长的领域。

查询模式

这是实际为 AI 代理内存查询的方式：

-- Get recent decisions for context
SELECT title, decision, rationale, decided_at
FROM architecture_decisions
WHERE project_id = ?
  AND decided_at > DATE_SUB(NOW(), INTERVAL 30 DAY)
ORDER BY decided_at DESC
LIMIT 10;

-- Find high-confidence patterns
SELECT category, name, description, code_example
FROM code_patterns
WHERE project_id = ?
  AND confidence_score >= 0.80
ORDER BY usage_count DESC, confidence_score DESC
LIMIT 20;

-- Check for known pitfalls before implementing
SELECT title, description, how_to_avoid
FROM pitfalls
WHERE project_id = ?
  AND category = ?
  AND severity IN ('critical', 'high')
ORDER BY encountered_count DESC;

-- Track session context across interactions
SELECT context
FROM work_sessions
WHERE session_id = ?
ORDER BY started_at DESC
LIMIT 1;

这些是直截了当的 SQL 查询。EXPLAIN 显示索引使用完全符合预期。没有惊喜。

Neo4j 层

MySQL 处理结构化数据。Neo4j 处理关系：

// Create nodes for decisions
CREATE (d:Decision {
  id: 'dec_123',
  title: 'Use FastAPI',
  project_id: 1,
  embedding: [0.23, -0.45, ...]  // Vector for similarity
})

// Create relationships
CREATE (d1:Decision {id: 'dec_123', title: 'Use FastAPI'})
CREATE (d2:Decision {id: 'dec_45', title: 'Used Flask before'})
CREATE (d1)-[:SIMILAR_TO {score: 0.85}]->(d2)
CREATE (d1)-[:CONTRADICTS]->(d3:Decision {title: 'Avoid frameworks'})

// Query: Find similar past decisions
MATCH (current:Decision {id: $decision_id})
MATCH (current)-[r:SIMILAR_TO]-(similar:Decision)
WHERE r.score > 0.80
RETURN similar.title, r.score
ORDER BY r.score DESC

// Query: What outcomes followed this pattern?
MATCH (d:Decision)-[:LEADS_TO]->(o:Outcome)
WHERE d.title CONTAINS 'Redis'
RETURN d.title, o.type, o.success_rate

它们如何协同工作

流程如下所示：

AI 代理生成内容或做出决策
将结构化数据存储到 MySQL（什么、何时、为什么、完整上下文）
生成嵌入，向量存储到 Neo4j，并与相似项目建立关系
下次会话：Neo4j 找到相关的相似决策
MySQL 提供这些决策的完整细节

MySQL 是真相之源。Neo4j 是模式查找器。

为什么不只用向量数据库？

我见过团队试图仅用 Pinecone 或 Weaviate 构建 AI 代理内存。但效果不佳，因为：

向量数据库擅长：

找到与查询相似的文档
语义搜索 (RAG)
“类似这样的东西”

向量数据库不擅长：

“我们 3 月 15 日决定了什么？”
“显示导致中断的决策”
“这个工作流的当前状态是什么？”
“哪些模式置信度 > 0.8 且使用次数 > 10？”

这些查询需要结构化过滤、连接和事务。这是关系型数据库的领域。

MCP 和未来

模型上下文协议 (MCP) 正在标准化 AI 系统处理上下文的方式。早期的 MCP 实现正在发现我们早已知道的事情：你需要结构化存储和图关系两者兼备。

``````html

MySQL 处理 MCP 的“resources”和“tools”目录。Neo4j 处理上下文项之间的“relationships”。Vector embeddings 只是拼图中的一块。

生产环境说明

当前运行此架构的系统：

MySQL 8.0, 48 tables, ~2GB data
Neo4j Community, ~50k nodes, ~200k relationships
Query latency: MySQL <10ms, Neo4j <50ms
Backup: Standard mysqldump + neo4j-admin dump
Monitoring: Same Percona tools I've used for years

运营复杂度低，因为这些是成熟的数据库，具有良好理解的运营模式。

何时使用什么

Use Case	Database
Workflow state, decisions, audit trail	MySQL/PostgreSQL
Pattern detection, similarity, relationships	Neo4j
Semantic document search (RAG)	Vector DB (optional)

从 MySQL 开始用于状态管理。当需要模式识别时添加 Neo4j。只有在实际进行语义文档检索时才添加 vector DB。

总结

AI 代理需要持久化内存。不仅仅是 vector database 中的 embeddings - 结构化、关系型、时序内存，带有模式识别。

MySQL 处理结构化状态。Neo4j 处理图关系。它们共同提供 vector databases 单独无法提供的功能。

不要为了 AI 工作负载而放弃关系型数据库。为每个任务使用正确的工具，那就是将两者结合使用。

有关此架构的 AI 代理视角，参见 3k1o 的配套文章。

另一個MySQL DBA

Pages

2026年2月22日星期日

MySQL + Neo4j 用于 AI 工作负载：为什么关系型数据库仍然重要

架构