用途：当决策重点不是数仓建模，而是选择承载状态、响应请求或支撑数据驱动应用流程的运行型数据存储时，使用本技能。它引导智能体在关系型系统（如 MySQL、PostgreSQL）与文档、键值、宽列、缓存型等 NoSQL 家族之间进行有意识的选择。
适用场景：为面向应用或服务的数据选择 MySQL 与 NoSQL；为元数据、幂等键、会话状态、事件状态或运行型 API 选型；判断灵活模式与严格关系约束哪个更重要；评估一致性、规模与访问模式权衡；避免把分析或管道系统误用为 OLTP 存储。
工作流：先定义访问模式，包括读写比、延迟期望、查询形态、更新频率、保留与归档行为；再定义完整性与一致性需求，包括事务、连接与关系约束、唯一性保证、冲突处理、对最终一致性的容忍度；然后将工作负载匹配到合适的存储家族——关系型适合事务、约束和可预测关系查询，文档型适合实体形态多变且以文档检索为主，键值型适合以键查找且访问模式较窄，宽列型适合规模与分区导向访问，缓存应加速另一真实数据源而非静默替代它；接着检查下游与运维影响，如 CDC 与复制支持、备份恢复、模式演进痛点、可观测性与运维成熟度、分析或数仓摄取方式；最后显式记录权衡，说明所选存储不擅长什么。
常见误区：认为“NoSQL 扩展更好”就选它，规模只是一个维度，事务、可运维性和查询体验仍重要；认为关系型过时，但成熟关系系统在一致性与关系完整性为核心时仍是强选择；认为模式变化多就必须用无模式存储，频繁形态变化往往信号是契约不清。
红旗信号：用数仓或湖仓充当运行型键值存储；选 NoSQL 却无明确访问模式依据；设计需要关系事务却遗漏；把缓存当作唯一真实数据源；不清楚 CDC、备份或迁移行为。
验证：访问模式与延迟需求已明确；完整性与一致性要求已命名；所选存储家族匹配实际工作负载；理解 CDC、备份、迁移与分析影响；权衡与非目标已记录。