# Proposal: Analysis Storage Refactor

## 问题背景

当前 `futures_analysis.db` 是独立的 SQLite 数据库，存储 14 张表（AI 分析、复盘计划、交易记录等）。与行情数据（已迁移到 MySQL/Redis）分离存储，存在以下问题：

1. **数据孤岛**：分析数据与行情数据分离，无法统一管理和备份
2. **扩展性差**：SQLite 不适合高并发读写场景
3. **架构不一致**：行情数据已采用 Redis→MySQL→SQLite 三级降级策略，分析数据仍使用单一 SQLite

## 目标

将 `futures_analysis.db` 的 14 张表迁移到 MySQL `buffer_platform` 数据库，并引入 Redis 缓存层，与行情数据存储策略保持一致。

## 范围

### 包含

- 复用现有 MySQL 连接（`mysql_engine`）和 Redis 连接（`redis_client`）
- 实现三级降级：Redis 缓存 → MySQL 持久化 → SQLite 兜底
- 启动时自动迁移现有 SQLite 数据到 MySQL
- 保持 ORM 模型定义不变
- 保持 API 接口不变

### 不包含

- 行情数据存储（已完成）
- 前端代码修改
- 新增业务功能

## 非目标

- 不改变现有 ORM 模型定义
- 不改变 API 接口签名
- 不引入新的业务逻辑

## 验收标准

1. 启动时检测 MySQL/Redis 可用，自动创建 analysis 表并迁移数据
2. API 读写 analysis 表时优先使用 Redis 缓存，未命中回源 MySQL
3. MySQL 不可用时降级到 SQLite
4. 现有功能（AI 分析、复盘计划、交易记录）正常工作
5. 单元测试覆盖三级降级场景

## 风险

| 风险 | 缓解措施 |
|------|----------|
| 数据迁移失败 | 保留 SQLite 作为降级方案，迁移失败时自动降级 |
| Redis 缓存一致性 | 写入时先删缓存，再写 MySQL，最后回填缓存 |
| 表结构不兼容 | 复用现有 ORM 模型，MySQL 自动创建表结构 |