4. drop大表影响TiDB、OceanBase、PolarDB-X均可以平滑删除，对在线业务无影响。5. 应急限流场景介绍：应急限流用于在线上紧急情况下，对部分烂SQL或者问题SQL进行紧急限流，保证大多数业务正常的情况下，限制部分烂SQL的运行，可用于紧急线上恢复。
6. 资源隔离场景介绍：用户验证是否支持oltp和olap场景自动资源隔离，olap通常需要大量的数据查询分析资源，如果无法资源隔离有可能影响在线业务的使用和稳定性。
7. 动态索引绑定场景介绍：用于测试执行计划绑定能力
TiDB：
1. 开启了实验室特性(plan cache)，不建议生产直接使用。生产环境默认不开启的话，point_select性能会有60%左右的性能下降，100核左右的资源点查场景只有36万QPS
2. sysbench测试场景中，会有比较大量的where id between xx and xx，但在实际业务中单纯基于用户id或者交易id的范围查询意义并不大，更多是在时间范围的查询。TiDB基于Range的分区策略，在between的分区裁剪可以做到只访问1个数据分片，而PolarDB-X和OceanBase基于Hash的策略会访问5个数据分片，因此TiDB的数据结构会在sysbench单纯指标能力上占一定的优势。ps. 针对Range 和 Hash分区的性能差异，在PolarDB-X上基于read only场景下跑了下Range分区的对比测试，Range相比于Hash分区差不多有45%左右的性能提升(28万 vs 19万)
3. TPC-C场景下，整体劣势比较明显
4. TPC-H场景下，在tilfash模式下性能表现不错，但在普通的tikv模式下，部分SQL跑不出结果
5. 特殊场景下，加索引的DDL性能有待提升，支持json但不建议生产使用，以及在热点行更新下有明显瓶颈
OceanBase：
1. 非分区表(通常理解的单表)，在OceanBase内部会在分布式多个节点上做表级别的均衡，一张表的数据只在一个节点，不同表可以在不同的节点，在非分区表下比较考验纯单机的能力。针对sysbench场景下的多张表在测试过程中是完全独立的，这样可以充分利用"多个单机"跑出一个更好的总吞吐值。这样的模式下，相比于TiDB会有30%~70%的优势，多个独立的单表模式在真实业务场景中一般需要配合业务端的分库分表。
2. 分区表，在OceanBase内部支持将一张表的数据分布到多台机器上，实现行级别的水平扩展能力，在分区表下会存在分布式事务、分片聚合查询等额外代价，是最考验分布式能力的地方。分区表和 非分区表在sysbench的性能测试结果上，两者的性能差异巨大。尤其在写入和混合读写场景，分区表只有单表测试的1/5左右，分布式事务的性能还需要有进一步的提升空间。
3. TPC-C场景下表现优秀。在TPC-H场景下，通过并行计算 行存整体表现不错。
4. 特殊场景下，不支持json，以及在热点行更新下有明显瓶颈。
PolarDB-X：
1. 非分区表(通常理解的单表)，PolarDB-X上支持通过locality模式将表分配到不同的节点，一张表的数据只在一个节点上，比较考验纯单机的能力。针对纯读和混合读写场景，相比于TiDB会有2~2.5倍的性能优势。
2. 分区表，在PolarDB-X内部支持将一张表的数据分布到多台机器上，实现方式和TiDB、OceanBase分布式表基本一致，在write only上整体性能会比TiDB好一些；在最常见的业务场景read write下，分区表和单机表性能都比OB要好很多，非分区表比TIDB有明显的性能优势，分区表跟tidb基本保持一致
3. TPC-C场景下表现优秀。在TPC-H场景下，通过并行计算 行存整体表现不错
4. 特殊场景下，快速加列DDL需要优化，支持json，以及针对热点更新的优化明显。
polardb-x对分区规则变更支持最好，基本支持所有常见的分区变更策略
总结1. PolarDB-X/OceanBase/TiDB在分布式水平扩展的性能上大同小异，区分度并不大。
2. TiDB有一些不错的实验性质的功能(比如plan cache、json)，对性能和功能易用性帮助比较大，但眼下生产不推荐使用。
3. OceanBase的模型比较复杂，测试场景需要充分理解分区表和 非分区表(单表)。在非分区表(单表)模式下，性能表现不错，重点考察的是纯单机能力，性能尚可，略低于MySQL。但分区表模式下，性能下降比较多，需要业务区分来看。
4. PolarDB-X功能性和易用性比较不错，json、大事务、热点更新支持比较完整。在非分区表(单表)模式下，纯MySQL单机的能力表现突出，在分区表模式下，可以通过分布式能力进一步扩展性能，对分区表的变更策略支持最完善。（完）
