技术上支持某能力，不代表该被用于对应的场景：HAWQ支持事务但不推荐做OLTP

HAWQ虽然支持分布式事务的所有ACID属性，采用Snapshot Isolation隔离级别，理论上完全具备被用来支撑事务性、高频小写入的OLTP（联机事务处理）场景的技术能力，但团队明确给出了自己的定位建议：”虽然HAWQ支持分布式事务，可以保证一致性，但不推荐用作OLTP，因为我们是针对OLAP进行优化的”——一个系统真正能被验证的、值得信赖的适用场景，是它的整体架构和内部优化方向所服务的目标，而不是它技术上”能不能做到”这件事本身。HAWQ整个架构（弹性执行引擎、并行查询优化器、大规模并行数据交换网络）从一开始就是围绕OLAP（联机分析处理，典型特征是复杂查询、大批量数据扫描、相对低频的写入）这个目标去做优化的，事务支持只是为了保证在这种分析场景下数据一致性所需要的一项能力，而不是这个系统的核心优化方向；如果强行把它用在OLTP这类要求极高并发、极低延迟单点写入的场景，即使技术上”跑得通”，也很可能因为架构本身没有针对这类负载优化而表现不佳。这个案例提示了一条评估任何系统”能不能用来做某件事”的重要原则：判断一个系统是否适合某个场景，不能只看它的功能清单里有没有勾选到相关能力，而要审视这个系统的核心架构设计、优化方向究竟是围绕什么样的负载特征展开的——一项能力”存在”，和这项能力”被充分优化、被系统设计者作为主要目标”，是完全不同的两回事；一个明明白白告诉你”我们支持A能力，但不建议你用来做A”的系统设计者，往往比一个只罗列功能清单、不主动说明适用边界的系统，更值得信赖。