一个租户在同一个 Server 上可以有一个或多个资源单元 UNIT （T）
创建资源单元仅仅指定 CPU、MEMORY 参数即可，无需指定 OPS、DISK_SIZE、SESSION_NUM 参数 (F)
OCEANBASE 在少数副本不可用的情况下，可以实现 RPO=0,RTO<30 秒 (T)
Zone 可以对应不同的城市，或者一个城市的不同机房、或者一个机房的不同机架，以实现不同级别的容灾 (T)
主副本只能打散到所有 Zone 内，实现访问流量的负载均衡，不能将主副本聚焦到一个Zone 内 (F)
OceanBase 已发布到阿里云公有云及专有云中 (T)
扩容服务器加入集群后，集群会基于负载均衡的策略，将主副本及从副本迁移到扩容服务器中，以实现整体的负载均衡 (T)
租户逻辑上类似传统数据库实例，创建完成后，每个租户都拥有自己的专属进程 (T)
OceanBase 的 Paxos 协议，不同于传统的主备库或者双选方案，可以彻底规避在容灾场景下的脑裂问题（也就是同时有两个主数据库的场景） (T)
TCP-C 就是一个跑分测试，官方没有什么规则现值，只要能跑高分就行 (F)
每台 OB Server 是相对独立的，都有自己独立的 SQL引擎，如果应用需要的数据不在当前 OB Server 上，该 OB Server 将协调其他 OB Server 的数据，统一反馈给应用，这个过程对应用是透明的。 (T)
修改资源池可以实现租户的另一种扩容/缩容的方式，比如在每个 zone 中增加/减少节点数量，可以通过修改资源池的 unit_num 来实现 (T)
创建租户时，需要指定租户类型为 Oracle 租户或者 MySQL 租户，以满足不同开发者的需求 (T)
同一个资源单元定义 unit cofig(比如 2C8G，或者 4C16G 等)，可以被多个资源池使用。(F)
分库分表的架构虽然解决了集中式数据库的扩展性问题，但也带来了新的问题（不支持复杂SQL，较难保证分布式事务的 ACID等)。(T)
利用覆盖索引来进行查询操作，来避免回表操作，提高检索性能 （T）
OceanBase数据库是在阿里和蚂蚁内部孵化了10年后才逐步推广到外部市场的。(T)
OceanBase数据库是基于开源数据库的再发行产品。(F)
OceanBase只支持X86架构的CPU，不支持国产CPU（如鲲鹏、海光、飞腾等)。(F)
Zone是个逻辑概念，是给集群内的一批机器打上同一个tag，属于同一个tag的服务器归属一个Zone。(T)
租户的资源池一旦创建完成，就不可改变。如果需要扩容，需要删除l旧资源池，创建一个更大规模的资源池。(F)
分区的副本只包含硬盘上的静态数据(SS Table)，不包括MemTable数据和日志数据。(F)
主副本只能打散到所有Zone内，不能聚焦到一个Zone内。(F)
主副本通过同步Redo-Log日志的方式实现可靠性，主副本需要收到所有从副本落盘成功的消息后才能响应应用。(F)
企业在一个城市有2个机房，将2个zone部署到1个机房中，将另一个Zone部署到另一个机房中，可以提供机房级的容灾。(F)
OceanBase可以支持在一个数据库中同时支持MySQL租户和Oracle租户。(T)
使用Explain命令查看SQL执行计划时，SQL也会真正执行。(F)
合并必须依赖OceanBase自动完成，无法手工启动合并。(F)
oceanBase中的磁盘数据按主键有序排列。(T)
会话变量只对当前会话生效，不影响该租户下的其他会话。(T)
Global级（租户级）变量修改后，对当前已经打开的session也依然生效。(F)
如果同时存在集群级别参数和租户级别参数，那么集群级别参数将覆盖租户级别参数。(T)
OBProxy在路由过程中，如果发现OBServer不可用，会把该OBServer加入到黑名单。（T）
应用通过OBProxy连接到OceanBase集群，比直连主副本所在的OBServer性能更好？（F）
对于已经创建的MySQL类型的租户，可以修改租户级别的全局变量ob_compatibility_mode，修改成ORACLE，该租户就变为 Oracle类型的租户了.(F)
OceanBase通过Explain命令查看优化器针对给定SQL生成的逻辑执行计划，Explain所展示的计划是在执行命令时优化器根据当前的用户输入和数据统计信息所生成的逻辑执行计划，而并不是在计划缓存中真正被使用的物理执行计划。(T)
