全系统key配对升级 bug20
配对维度优化后系统缺陷与不足分析
在全系统 Key 已改为 (symbol, base_symbol) 配对维度的前提下，对当前实现做一致性检查，识别仍存在的缺陷与不足，并给出可落地的改进建议。
一、当前配对维度改造已到位的部分（简要）
- 核心状态与存储：策略 (strategy.py)、仓位 (position_manager.py)、编排 (orchestrator.py)、交易仓库 (trade_repository.py) 均按
PairKey = (symbol, base_symbol)维度存储与查询。 - 数据库：迁移 20260219_fix_pairkey_indexes.sql 已将
trading_signals、pair_positions、analysis_results的索引与压缩分段统一为(symbol, base_symbol)；黑名单表与协整表本身即为配对维度。 - 配置与黑名单：
TradingConfig.is_symbol_allowed/is_close_disabled支持配对级（如PURR|HYPE）与币种级；黑名单缓存与 DB 均为(symbol, base_symbol)。 - 启动与数据流：orchestrator 从 DB 按
(symbol, base_symbol)灌 z4h 缓冲区；策略prime_buffer、仓位恢复、交易所同步均按配对维度处理。
二、仍存在的缺陷与不足
1. analysis_results 去重键与业务唯一性不一致（中）
- 现状：写入前去重键为
(analysis_time.replace(microsecond=0), symbol, base_symbol)（realtime_kline_service_base.py 约 790–792 行）。即“同一秒、同一配对”只保留一条，未包含kline_time。 - 问题：业务上期望的是“每个配对、每个 K 线时间点一条记录”，即唯一性应为
(symbol, base_symbol, kline_time)。当前逻辑下，同一kline_time若被不同批次的analysis_time写入，会插入多条，导致：- 存储冗余；
- 依赖下游用
PARTITION BY symbol, base_symbol, kline_time ORDER BY analysis_time DESC取“最新一条”才能得到正确语义（orchestrator 已这样用，但属隐式约定）。
- 建议：
- 应用层去重键改为
(symbol, base_symbol, kline_time)，同一配对同一 kline_time 只保留一条（例如保留 analysis_time 最新的一条）； - 若希望从根上约束，可在 DB 增加唯一约束或唯一索引（需考虑 analysis_results 为 Hypertable、分区键为 analysis_time 的现状，可能要做唯一索引时包含 analysis_time 或改用 kline_time 分区，评估迁移成本后再定）。
- 应用层去重键改为
2. 历史压缩 Chunk 仍为旧分段方式（已知遗留，低）
- 现状：迁移脚本已说明：“已压缩的历史 chunk 仍使用旧分段方式；新写入数据将使用 (symbol, base_symbol) 分段压缩。”（20260219_fix_pairkey_indexes.sql 约 56–58 行）
- 影响：旧 chunk 按 symbol 分段，按 (symbol, base_symbol) 查询时压缩效果与扫描范围非最优，但不影响正确性。
- 建议：若需统一压缩与查询性能，可对历史 chunk 执行
decompress_chunk+recompress（需在低峰期、评估 I/O 与锁）。
3. daily_trading_stats 未按配对维度统计（设计取舍，低）
- 现状：表已增加
symbol、base_symbol列（20260220_bugfix_batch.sql），但 trade_repository.update_daily_stats 仍按(stat_date, network)主键做全局累加，未写入也未使用 symbol/base_symbol（代码注释已说明为预留、当前未使用）。 - 影响：无法按配对维度做日报、回测或风控分析；多配对运行时无法区分各配对的信号数、开平仓数、盈亏。
- 建议：若后续需要按配对统计，需将主键改为
(stat_date, network, symbol, base_symbol)或增加配对维度聚合表，并修改update_daily_stats的调用处传入(symbol, base_symbol)并在 INSERT/UPDATE 中使用。
4. get_positions_by_symbols 仅按 symbol 过滤（设计合理，需文档化）
- 现状：TradeRepository.get_positions_by_symbols 使用
WHERE symbol = ANY(%s)，即按“目标币种（alt）”列表查所有开放中的仓位，不按 base_symbol 过滤。 - 使用处：仅 position_manager 在恢复/收纳时传入“候选 alt 列表”，再在内存中按
(symbol, base_symbol)处理，语义正确。 - 建议：在方法 docstring 中明确“按 alt symbol 列表查询，返回所有匹配的 (symbol, base_symbol) 仓位”，避免后续被误用为“按配对 key 查询”。
5. cointegrated_pairs 与系统命名不一致（可读性，低）
- 现状：表与仓库使用
(base_symbol, alt_symbol)，代码与其它表普遍使用(symbol, base_symbol)表示 (alt, base)。 - 影响：仅命名/可读性，易与“symbol”混淆；逻辑上 alt_symbol ≡ symbol、base_symbol 一致。
- 建议：在 CoIntegratedPairsRepository 或表注释中明确“alt_symbol = 目标币种 = 其它模块的 symbol；base_symbol = 基准币种”，必要时在仓库方法参数名上保持 symbol/base_symbol 以与全系统统一。
6. 策略参数与配置的配对粒度（已支持，无缺陷）
- 现状：
get_strategy_params(symbol, base_symbol)、黑名单/禁止平仓的配对级格式均支持；环境变量中TRADING_SYMBOL_BLACKLIST、TRADING_CLOSE_DISABLED_SYMBOLS支持PURR|HYPE与单币种。 - 结论：配置层与配对维度一致，无缺陷。
7. 脚本与工具脚本的配对维度（小缺口，低）
- 现状：如 check_buffer_continuity.py 的
query_startup_buffer已支持base_symbol参数且默认与 orchestrator 语义一致；main()使用默认BASE_SYMBOL，未传时即单配对检查，可接受。 - 建议：若有多配对运维需求，可为脚本增加
--base-symbol或从 cointegrated_pairs 自动枚举配对，便于按配对做缓冲区/连续性检查。
三、架构与数据流核对（无问题）
- 分析节流：按
(symbol, timeframe)节流，单 K 线一次分析、内部再按多个 base 循环，配对维度在分析内部体现，设计合理。 - 黑名单恢复：
get_active(base_symbol=None)拉全量，缓存 key 为(symbol, base_symbol)，正确。 - 数据自愈：按
(symbol, base_symbol)从 analysis_results 取有数据的配对并与 pair_cache 交集，逻辑正确。
四、总结与优先级建议
| 类别 | 项 | 严重程度 | 建议优先级 |
|---|---|---|---|
| 数据一致性/语义 | analysis_results 去重键不含 kline_time，导致同一 (pair, kline_time) 可多行 | 中 | 高：改应用层去重键为 (symbol, base_symbol, kline_time)；可选 DB 唯一约束 |
| 存储/性能 | 历史压缩 chunk 仍为旧分段 | 低 | 低：按需 decompress + recompress |
| 统计/运营 | daily_trading_stats 未按配对统计 | 低 | 中：若要做按配对报表再改主键与写入逻辑 |
| 可维护性 | get_positions_by_symbols 文档化 | 低 | 低：补充 docstring |
| 可维护性 | cointegrated_pairs 命名与注释统一 | 低 | 低：注释或参数命名统一 |
整体上，全系统 Key 改为配对维度后，核心交易与仓位路径已一致且正确；主要改进点集中在 analysis_results 写入去重语义 与可选的数据/统计增强（历史压缩、按配对日报、脚本可配置配对）。