TDSQL Boundless 引擎与原生 MySQL 在读写性能上有何差异？
TDSQL Boundless 是一款原生分布式数据库。它通过 Raft 协议在数据单元的副本之间保持一致性，默认情况下每个数据单元有三个副本，并且这些数据均匀分布在所有数据节点上。这种数据分布策略极大地提升了处理大量写入操作的效率，尤其在写多读少的业务场景中表现出色。
与 MySQL 的 InnoDB 存储引擎相比，TDSQL Boundless 能够实现3 ~ 9倍的数据压缩率，这不仅有效减少了存储空间的需求，还可能提高写入 I/O 性能。因此，TDSQL Boundless 特别适合那些对写入性能有较高要求的场景。
基于 LSM-tree 的 TDSQL Boundless 查询性能是否低于原生 MySQL？
与 MySQL 的 B+ 树索引相比，LSM-tree（Log-Structured Merge-tree）在写入性能上有显著优势，但在读取性能上可能会有所牺牲。
然而，TDSQL Boundless 作为一款分布式数据库，提供了多种机制来提升查询性能：
1. 垂直/水平扩容：TDSQL Boundless 可以通过增加更多的节点来扩展数据库的处理能力，从而提高每秒查询率（QPS）。这是单机 MySQL 无法实现的，因为单机 MySQL 的性能受限于单个服务器的硬件资源。
2. 优化策略：即使在单节点上，TDSQL Boundless 也采用了一系列优化策略来提高读取性能：
Leveling Compaction：TDSQL Boundless 将所有数据（包括主键和索引）存储在一个大的、有序的键值对空间中，这些数据在物理磁盘上对应多个 SST 文件，分为 L0 到 L6 共七层。Leveling Compaction 策略确保了除了 L0 层之外的每一层中键的唯一性，这有助于加快查询速度。L0层较为特殊，允许文件间存在范围重叠，但 TDSQL Boundless 会限制 L0 层的文件数量，通常不超过四个。当需要访问数据时，TDSQL Boundless 首先检查内存 memtable，如果数据不在 memtable 中，则按层次顺序检查磁盘上的 SST 文件。由于 L1 到 L6 层的键是唯一的，因此每层只需检查一个 SST 文件即可确定目标数据是否存在。
Bloom Filter：在查找数据时，TDSQL Boundless 使用布隆过滤器来快速排除那些不可能包含目标键的 SST 文件，这样可以避免不必要的磁盘查找，节省资源。
Block Cache：TDSQL Boundless 利用块缓存来存储热点数据，减少对磁盘的 I/O 操作，进一步提高读取性能。
综上所述，尽管基于 LSM-tree 在普遍印象中是写强读弱，但实际通过一系列工程优化其读取速度也完全可以覆盖各类高并发低延迟的在线场景。与此同时，TDSQL Boundless 由于其分布式的特性，可单实例达到百万以上吞吐，这是传统架构所无法实现的性能目标。
TDSQL Boundless 的 Compaction 对性能有何影响？
TDSQL Boundless 中的 Compaction 过程主要包括两个动作：读取上一层文件，进行 sort-merge 操作，然后将结果写入下一层或下几层的文件。这个过程主要消耗 CPU 和 I/O 资源。因此，只要系统有足够的资源，Compaction 本身通常不会对业务性能产生明显的影响，甚至可能没有影响。
此外，由于 TDSQL Boundless 采用天然的分布式架构，它可以利用所有节点的资源来进行 Compaction，这与传统的主从架构不同，在主从架构中，通常只有主库的资源被用于处理读写操作（不考虑读写分离的情况）。因此，TDSQL Boundless 的分布式特性有效地弥补了可能需要为 Compaction 准备额外资源的问题。
关于 Compaction 对性能影响的担心，很大程度上是因为早期 RocksDB 实现中相对简单的 Compaction 策略，这留下了一些关于 Compaction 影响的 "传说"。然而，随着版本的不断迭代，Compaction 策略已经进行了大量的优化，使得对性能的影响更加可控。
TDSQL Boundless 在读取场景中是否存在性能问题？如何确定数据分片的位置？
在 TDSQL Boundless 分布式数据库中，读取性能可能会受到数据分片和查询方式的影响。以下是两种常见的情况：
带分区键的查询：如果查询中包含了分区键，TDSQL Boundless 能够直接将查询路由到包含该分区键的具体数据分片上。这种方式非常高效，因为它避免了不必要的数据遍历，直接定位到了正确的数据节点。
不带分区键的查询：当查询没有指定分区键时，TDSQL Boundless 需要通过二级索引来确定数据的位置。这种情况下，系统会在包含该表数据的节点上进行遍历查询，这可能会导致性能上的轻微下降，因为需要检查更多的数据。
InnoDB 与 TDSQL Boundless 在大事务主备延迟问题上是否有相同的表现？
InnoDB 和 TDSQL Boundless 在处理大事务主备延迟问题上表现出不同的特性：
InnoDB：InnoDB 使用二进制日志（binlog）来同步主备数据。在高并发和大数据量的场景下，大事务可能会导致主备之间的延迟，因为 binlog 的复制和重放过程可能会很耗时。
TDSQL Boundless：TDSQL Boundless 是一个基于 Raft 协议的分布式数据库，它通过 Raft 日志实时同步节点间的数据。在 Raft 协议中，Leader 节点会在接收到客户端请求后，先将请求作为一个新的日志条目添加到本地日志，然后复制到 Follower 节点。只有当日志条目被复制到多数派节点并被标记为可提交状态后，Leader 节点才会响应客户端。这种设计有效减少了大事务可能导致的延迟。
在 TDSQL Boundless 中，主备节点之间的 apply 操作几乎不会有延迟。唯一的潜在延迟是 Follower 节点需要等待 Leader 节点发送下一个日志条目（或心跳）来获取可以提交的索引。然而，这个时间间隔通常非常短，可以忽略不计。
此外，TDSQL Boundless 对事务的大小有限制，尤其是对于删除操作，建议将大事务拆分成多个小事务执行。这有助于避免单个事务占用过多资源，减少对系统性能的影响。
综上所述，与 InnoDB 相比，TDSQL Boundless 的 Raft 协议同步机制在大事务处理上提供了更低的主备延迟，特别是在高并发和大数据量的场景下。