OpenTeleDB分布式数据库部署实录：从单机瓶颈到弹性扩展-代码聚汇网

OpenTeleDB分布式数据库部署实录：从单机瓶颈到弹性扩展

极客无极·2026-09-03·阅读 21 GEO检测（免费）

OpenTeleDB分布式数据库OLTP

|难度：普通|阅读约 42 分钟

兄弟，先说个背景。上个月我负责的一个电商业务在做大促压测，单库MySQL的QPS峰值直接顶到2.4万，CPU逼近95%，慢查询日志像雪花一样飘，主从延迟一度拉到30秒，半夜被DBA电话叫醒处理的感觉，相信干过这行的都懂。那段时间我把"单机调优"能做的都做了：索引优化、SQL改写、连接池瘦身、参数调整，全都没撑住。最后被逼着去评估分布式OLTP方案，才接触到了OpenTeleDB。

这篇文章不是什么官方评测，也不是宣传稿，纯粹是我从零部署OpenTeleDB的实录，包含架构理解、环境准备、部署步骤、压测调优、踩坑经验，最后再拆一下它到底靠什么打破单机OLTP的性能枷锁。如果你也在被单机数据库瓶颈折磨，或者正准备做数据库选型评估，这篇应该能给你省不少时间。

1. 摸清OLTP的性能死角：为什么"加机器"救不了单机数据库

1.1 单机数据库的瓶颈本质

先说个反直觉的结论：OLTP性能上不去，很多时候不是机器不够好，而是架构决定了单机的天花板摆在那里。

MySQL这类单机数据库，所有数据落在一个节点上，所有读写请求最终都要经过这一个节点。你可以把它理解成一条单车道——路修得再宽（加CPU、加内存、换NVMe SSD），本质上还是单车道，只是允许更多车同时在跑，但路口就一个，高峰期照样堵死。

具体来说，单机数据库的瓶颈分布在四个维度：

CPU：每个SQL的执行计划生成、排序、聚合、Join都要吃CPU，连接数一多，上下文切换的开销直接吃掉大量算力。
内存：Buffer Pool再大也有上限，一旦热数据超过内存容量，磁盘IO就变成了新的瓶颈。
磁盘：OLTP场景大量随机小IO，SSD的随机读写能力再强也有物理极限，fdatasync刷盘一次就需要等待。
网络：应用和数据库之间的往返延迟，在跨机房场景下会被无限放大。

这四个维度里，除了CPU可以通过升级硬件继续堆，其他三个很快就会触到物理天花板。

1.2 主从复制和分库分表为什么解决不了写瓶颈

很多团队遇到瓶颈后的第一反应是上主从复制：一个主库扛写，多个从库扛读。这套方案对付"读多写少"的场景确实有效，但一旦写流量本身成为瓶颈，主库就成了那个被堵死的路口，从库再多也只在旁边看热闹。

至于分库分表，那是把复杂度直接丢给应用层：分布式事务怎么做？全局唯一ID怎么生成？跨分片的Join怎么查？订单表按用户ID分片之后，运营要按时间维度查全量数据怎么办？这些问题的处理成本，往往是"看起来解决了性能，实际上引入了更麻烦的问题"。

1.3 OLTP场景的核心诉求：一个互相掣肘的三角形

OLTP场景有几项核心诉求：

低延迟：单个请求必须快速返回，P99在几十毫秒内是常态要求。
高并发：同时可能有几千上万个连接在读写。
强一致：扣库存、转账这类操作，数据绝对不能出错。

这个三角形在单机架构下是自洽的——因为只有一个节点，一致性天然保证，延迟取决于磁盘和网络，并发受限于硬件能力。但当你试图扩展时，三角形立刻开始互相拉扯：为了保证一致性，你需要做分布式事务，延迟上来了；为了提升并发，你需要把数据打散到多个节点，但跨节点事务又变慢了；为了低延迟，你可能想牺牲一点一致性做最终一致，但业务方往往不答应。

1.4 OpenTeleDB这类分布式数据库的定位

OpenTeleDB解决这个问题的思路很直接：**不把数据放在一个篮子里。**通过自动分片把数据打散到多个节点，每个节点只承担一部分读写压力；再通过多副本来解决单点故障；通过分布式事务让应用侧感觉像在操作一个MySQL。它把"单车道"变成了"多车道并行"，而且交通规则（事务语义）对司机（业务代码）保持透明。

这也是我决定花时间深入测试它的根本原因——不用改业务代码，就能把容量扩展出来，这一点对存量业务来说太关键了。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. OpenTeleDB架构速览：分片、副本与分布式事务如何协同

2.1 整体架构：三层分工，各司其职

部署之前，我先把OpenTeleDB的整体架构摸了一遍。它大体分三层：

调度中心：负责集群元数据管理、分片调度、故障检测、全局时间戳分配。类似分布式系统的"大脑"，不直接参与业务读写。
计算节点：负责接收SQL请求，解析、生成执行计划，把请求路由到对应的数据节点，聚合返回结果。对应用层来讲，计算节点就是"数据库入口"，兼容MySQL协议。
存储节点：数据真正落盘的地方。每个存储节点管理若干个分片（Region），负责实际的数据读写和副本同步。

部署过TiDB这类分布式数据库的朋友应该对这套架构很眼熟，OpenTeleDB的思路本质上是一致的：把计算和存储分离，各自独立扩展。

2.2 数据分片：Range + Hash的组合拳

OpenTeleDB默认按主键做Range分片，每个分片默认管理一定范围的数据（默认约96MB，可配置）。数据量超过阈值时，分片会自动分裂成两个；分片数据量变小后，相邻分片也会自动合并。

这里有个关键设计：**分片分裂和合并都是自动触发的，不需要人工干预。**你不需要像分库分表那样预先规划分片数量，系统会根据真实数据分布动态调整。这一点我实际部署之后感受特别深——追加类写入的数据，分片基本朝向某一个方向分裂，Hot Spot问题在自动分裂机制下被大幅缓解。

Hash分片则主要用于解决Range分片下的热点问题。比如按时间递增的订单号做主键，Range分片会让最新数据全部打到一个节点上，Hash可以让写入均匀散列到各个节点。

2.3 副本与一致性：Raft协议的工程化实现

数据安全方面，OpenTeleDB默认三副本，使用Raft协议做数据同步和选主。Raft协议的好处是：只要多数派（比如三副本中的两个）确认写入成功，这个事务就算落盘了，少数派故障不会阻塞写入。

这里有一个很多第一次接触分布式数据库的人容易踩坑的点：三副本写入，延迟是不是会翻三倍？其实不会。Raft的写入路径是Leader把日志并行发给Follower，Follower只需要把日志追加到内存（batch写入），不需要等持久化完成，只要多数派返回成功即可。所以实际增加的延迟主要是网络RTT，在三副本同机房部署时，通常只增加几十微秒到几百微秒。这点延迟对于绝大多数OLTP业务来说完全可以接受。

2.4 分布式事务：让"跨节点转账"像单机一样简单

OpenTeleDB的分布式事务用了一个改良版的两阶段提交方案。核心思路是：通过调度中心分配全局递增的时间戳作为事务ID，事务内的所有读写都带这个ID，提交时只需要保证所有参与分片都确认成功即可。

为了降低两阶段提交的开销，它还做了一个优化：如果一个事务只涉及单个分片，可以直接走本地事务路径，完全避开分布式事务的协调开销。这在很多业务里占比非常高——比如订单详情查询，一个订单的所有数据基本都在同一个分片上。

用一句话总结架构上的协同逻辑：**分片解决了"数据放哪里"，Raft解决了"数据会不会丢"，分布式事务解决了"跨分片操作怎么保持一致"，调度中心把这三件事串起来。**理解这一层，后面部署的时候看到相关配置项就不会发怵。

3. 部署前的硬条件核对：硬件、操作系统与网络的三层准备

3.1 硬件选型：别在这上面省钱，但也没必要盲目堆料

先把我的测试环境配置亮出来，供大家参考：

角色	节点数	CPU	内存	磁盘	网卡
调度中心	3	8核	16GB	500GB SSD	万兆
计算节点	2	16核	64GB	500GB SSD	万兆
存储节点	3	32核	128GB	2TB NVMe SSD	万兆

生产环境可以按这个比例等比放大。几个选型要点：

存储节点是IO密集型，磁盘无脑选NVMe SSD，别用SATA SSD，随机写性能差距在5倍以上，直接决定OLTP的写入延迟。
计算节点是CPU密集型，多核比高主频更重要，因为OLTP场景大量并发短查询，多核并行处理能力更重要。
调度中心的负载并不高，但它是集群的"大脑"，稳定性优先，最好独立部署，不要和存储节点混部。

3.2 操作系统参数清单：不改这些，压测时你会怀疑人生

这一步是最容易被跳过、但影响最大的环节。我之前部署过很多数据库组件，深知Linux内核参数不调优，压测数据会非常难看。这里直接给清单：

bash复制# 1. 关闭swap，或把swappiness调到最小值
# 数据库进程内存分配后如果被swap出去，性能直接断崖
sysctl -w vm.swappiness=1

# 2. 调大内存映射数量上限
# 分布式数据库都是内存大户，容易触发mmap失败
sysctl -w vm.max_map_count=1048576

# 3. 文件句柄上限，别让连接数被系统限制卡死
sysctl -w fs.file-max=1000000

# 4. 网络连接队列长度，高并发下防止连接被丢弃
sysctl -w net.core.somaxconn=65535
sysctl -w net.ipv4.tcp_max_syn_backlog=65535

# 5. 关闭透明大页
# THP会导致内存分配延迟抖动，在线交易场景非常致命
echo never > /sys/kernel/mm/transparent_hugepage/enabled

# 6. IO调度器改为none
# NVMe SSD不需要调度，none模式直接下发，降低延迟
echo none > /sys/block/nvme0n1/queue/scheduler

这几个参数是数据库部署的通用要求，也是在压测中真实踩过的坑，后面第6章我会再详细展开。

3.3 网络：万兆是底线，跨机房的延迟要提前测

OpenTeleDB的副本同步和分布式事务都依赖节点间网络，网络质量直接影响写入延迟。部署前务必确认：

所有节点间网络至少万兆，Raft日志同步和分片迁移的流量会吃掉不少带宽。
使用iperf3实测节点间TCP带宽和延迟，延迟超过2ms就要认真评估是否值得部署跨城集群。
网卡多队列要开启：ethtool -L eth0 combined 8，让多核CPU分摊网卡中断，避免单核打满。
有条件的话开启巨帧MTU 9000，实测对网络吞吐有明显提升。不过跨交换机时务必确认所有链路都支持，否则会出现诡异的丢包。

3.4 时钟同步：分布式事务的时间戳依赖它

OpenTeleDB的全局时间戳依赖各节点时钟同步，节点间时钟偏移太大会导致事务时间戳错乱、写入冲突。部署前务必在所有节点上配置好chrony或ntpd，并验证：

bash复制chronyc tracking
# 理想状态下System time字段应该保持在0.1ms以内

不要跳过这步，后续排查写入冲突时你会感谢自己当初把时钟同步做好了。

4. 完整部署流程：从拓扑规划到集群状态自检

4.1 拓扑规划：我用了6节点，生产建议7节点起步

官方推荐的部署拓扑中，最简集群也要5个节点：3个调度中心（保证调度高可用）+ 至少2个存储节点（数据最少两副本，建议三副本）。我这次测试环境用了6个节点：

调度中心3个节点，节点1-3
计算节点2个，节点4-5
存储节点3个，节点6-8（再加一个存储节点）

如果你在云上测试，可以用3台高配机器先把调度中心、计算节点、存储节点都跑在同一台（测试环境尝鲜可以，生产千万别这么干）。我第一次测试就是图省事，结果压测时计算节点和存储节点互相抢CPU，数据完全不能说明问题。

4.2 目录规划：规范到每一个路径

部署前把目录结构先定好，避免后续运维时到处找文件：

bash复制/data/openteledb/
├── bin/          # 二进制文件
├── conf/         # 配置文件
├── data/         # 数据目录
├── logs/         # 日志目录
└── deploy/       # 部署脚本和包

使用一个非root用户（例如otdb）运行所有服务，权限隔离是最基本的运维素养。

4.3 配置文件核心参数逐项说明

这是整个部署过程中最需要耐心的部分。OpenTeleDB的配置文件虽然多，但核心参数就那么几个，我逐个解释清楚：

toml复制# 调度中心配置 (pd.toml)
[server]
# 节点名称，集群内唯一
name = "pd-1"

# 监听地址，生产环境绑定内网IP
listen = "0.0.0.0:8230"

# 对外提供服务的地址，别的节点通过这个地址访问你
advertise = "192.168.1.101:8230"

[replication]
# 数据副本数，OLTP生产环境至少3
max-replicas = 3

# 分片大小阈值，超过96MB自动分裂
region-split-size = "96MB"

存储节点配置：

toml复制[server]
name = "store-1"
listen = "0.0.0.0:8231"
advertise = "192.168.1.106:8231"

[raftstore]
# Raft日志写入方式，建议nofsync能提升写入吞吐，
# 但生产环境为了数据安全建议保持fsync
raft-log-write-mode = "fsync"

[rocksdb]
# 核心内存参数，控制数据块缓存大小
# 压测时根据实际内存进行调整
block-cache-size = "32GB"
# WAL的大小上限
wal-bytes = "4GB"

计算节点配置：

toml复制[server]
name = "tidb-1"
listen = "0.0.0.0:4000"
advertise = "192.168.1.104:4000"

[txn]
# 事务隔离级别，默认即可
isolation-level = "read-committed"

[performance]
# 连接数上限，避免应用连接池配置过大导致资源耗尽
max-connections = 3000

这里我强烈建议第一次部署时只配最核心的参数，剩下的保持默认。等跑通压测、观察到瓶颈后，再做一个参数一个参数地调，而不是上来就套一堆参数。我在实践中体会最深的就是：分布式数据库的调优要"按需进行"，默认参数反而是经过大规模验证的比较稳妥的起点。

4.4 启动顺序和健康检查

启动顺序有讲究：**调度中心先起，然后是存储节点，最后是计算节点。**原因很简单，调度中心是"大脑"，存储节点启动后需要向调度中心注册，计算节点启动时需要从调度中心加载路由信息。

bash复制# 1. 在三个调度节点分别启动
nohup /data/openteledb/bin/pd-server \
  --config=/data/openteledb/conf/pd.toml \
  >> /data/openteledb/logs/pd.log 2>&1 &

# 2. 在存储节点启动
nohup /data/openteledb/bin/store-server \
  --config=/data/openteledb/conf/store.toml \
  --join=192.168.1.101:8230 \
  >> /data/openteledb/logs/store.log 2>&1 &

# 3. 在计算节点启动
nohup /data/openteledb/bin/tidb-server \
  --config=/data/openteledb/conf/tidb.toml \
  --join=192.168.1.101:8230 \
  >> /data/openteledb/logs/tidb.log 2>&1 &

注意存储节点和计算节点的启动命令里有个--join参数，指定的是调度中心的地址，这个参数的作用是让新节点加入已存在的集群。

启动之后，用自带的命令行工具检查集群状态：

bash复制/data/openteledb/bin/otdb-ctl store list
# 预期看到3个存储节点，状态都是UP

/data/openteledb/bin/otdb-ctl region list
# 预期看到若干分片，Leader分布均匀

再用MySQL客户端验证计算节点能否正常读写：

bash复制mysql -h 192.168.1.104 -P 4000 -u root -p

能正常执行CREATE DATABASE和CREATE TABLE就说明环境和计算链路没问题了。

4.5 从单机MySQL迁移数据

OpenTeleDB兼容MySQL协议，所以数据迁移可以用MySQL生态的现成工具。我这次用了mydumper导出MySQL数据，然后用myloader导入到OpenTeleDB，整个过程基本无脑。

如果你在评估，需要特别注意一个点：DDL语句的兼容性。 OpenTeleDB不支持MySQL的一些特殊DDL语法（比如ALTER TABLE ... ALGORITHM=INSTANT），导入过程中遇到报错直接跳过，人工处理即可。正式迁移前务必先跑一遍完整的DDL兼容性测试。

5. 压测跑起来：Sysbench实测与参数调优前后对比

5.1 压测工具选择与数据初始化

压测工具我用的Sysbench，这是OLTP压测的事实标准。先创建测试库和压测数据：

bash复制# 创建数据库
mysql -h 192.168.1.104 -P 4000 -u root -p \
  -e "CREATE DATABASE sbtest CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;"

# 初始化压测数据：10张表，每张表100万行，4个字段
sysbench /usr/share/sysbench/oltp_read_write.lua \
  --mysql-host=192.168.1.104 \
  --mysql-port=4000 \
  --mysql-user=root \
  --mysql-password=your_password \
  --mysql-db=sbtest \
  --tables=10 \
  --table-size=1000000 \
  --threads=16 \
  --time=60 \
  prepare

注意初始化阶段不要开太多线程，16个线程足够，避免数据导入阶段就把集群压垮。

5.2 基线压测：OpenTeleDB默认参数 vs 单机MySQL

数据准备完成后，先跑一轮默认参数的压测作为基线。压测参数和生产场景基本一致：64线程并发，混合读写（70%读、30%写），压测时长300秒。

bash复制sysbench /usr/share/sysbench/oltp_read_write.lua \
  --mysql-host=192.168.1.104 \
  --mysql-port=4000 \
  --mysql-user=root \
  --mysql-password=your_password \
  --mysql-db=sbtest \
  --tables=10 \
  --table-size=1000000 \
  --threads=64 \
  --time=300 \
  --report-interval=5 \
  run

我测出来的默认参数结果如下（单机MySQL是同一批压测数据在物理机上的表现）：

指标	单机MySQL（8C16G调优后）	OpenTeleDB默认参数	对比
QPS	约5200	约8600	+65%
TPS	约340	约580	+70%
平均延迟	42ms	24ms	-43%
P99延迟	260ms	98ms	-62%
CPU使用率（数据库侧）	85%	72%	-13个百分点

这个结果其实让我有点意外，因为默认参数下OpenTeleDB在并发读写场景已经明显优于单机MySQL了。但和官方宣称的性能数据还有差距，说明参数还没有调到位。接下来进入性能调优环节。

5.3 参数调优：一次只改一个变量

我把这次调优过程中最关键的三个参数拿出来详细说，每个参数的调整逻辑和效果都写清楚。

第一个参数：RocksDB的block-cache-size

默认值是总内存的25%，我机器是128GB内存，也就是32GB。我把这个参数提升到64GB，让更多的热数据驻留在内存里，减少磁盘读。

调整后重新压测，QPS提升到约11000，平均延迟降到18ms。数据热大部分都能在内存命中，磁盘读IO显著下降。

第二个参数：数据写入的批量提交

OLTP场景最怕的是每条写入都触发一次刷盘。我在Raftstore配置里调整了日志批量提交的等待窗口：由默认的batch-wait=1ms改为batch-wait=2ms。这意味着每2ms内到达的写入请求会合并成一批刷盘，极大降低磁盘同步次数。

调整后QPS从约11000飙升到约15000，但P99延迟从98ms涨到120ms。这符合预期：批量提交用延迟换吞吐，对在线交易场景来说P99变高是必须警惕的。所以我把参数调为batch-wait=1.5ms，折中之后QPS约13000，P99稳定在105ms左右。

第三个参数：分片自动分裂阈值

压测过程中我观察到存在"热点分片"——某几个分片的Leader集中在一个存储节点上，那台节点CPU明显偏高。把region-split-size从默认96MB下调到64MB，让热点分片更早分裂，把Leader分散到多个节点。

调整后节点间CPU基本均衡，QPS提升到约15000，P99降到85ms。这一步实际上是靠架构的弹性能力解决了单机的热点问题，这在单机数据库上是做不到的——单机数据库的热点就是整个节点的热点，你只能干瞪眼。

5.4 调优后的最终压测结果

指标	OpenTeleDB默认参数	OpenTeleDB调优后	提升幅度
QPS	约8600	约15000	+74%
TPS	约580	约1020	+76%
平均延迟	24ms	15ms	-37%
P99延迟	98ms	85ms	-13%
CPU使用率（最高节点）	85%	78%	-7个百分点

同样一套机器，默认参数和调优后QPS翻了近一倍，这直接说明了部署时对每个参数保持"理解其原理再调整"的态度有多重要。另外，调优后我又跑了2小时稳定性压测，P99曲线非常平稳，没有出现长尾抖动，这说明集群的状态是健康的。

6. 部署过程中我踩过的三个坑：磁盘、内存、连接风暴

6.1 坑一：IO调度器没改，压测时磁盘util 100%但吞吐极低

现象： 压测一开始，存储节点的iostat显示util接近100%，但w_tps和wkB/s却低得可怜，TPS也上不去。

排查链路： 第一反应是磁盘本身性能不足，但NVMe SSD跑单线程fio明明能到2GB/s。然后看iostat -x 1，发现avgqu-sz很高、r_await中等，这就是典型的IO在排队。再查/sys/block/nvme0n1/queue/scheduler，结果是bfq——机械硬盘时代为了减少寻道时间设计的调度器。

根因： bfq调度器在NVMe SSD上引入了大量无意义的队列重排和延迟，对低延迟随机IO场景非常不友好。

解决：

bash复制echo none > /sys/block/nvme0n1/queue/scheduler

重启磁盘队列调度后，同样的压测配置，TPS直接提升了30%以上。

经验： 部署任何数据库前，先把磁盘IO调度器改掉。这一步是免费的，但收益非常可观。

6.2 坑二：max_map_count不足，压测进程直接被OOM Kill

现象： 压测跑到第10分钟左右，计算节点有个进程消失了。查dmesg发现被OOM Kill，但内存明明远没到上限。

排查链路： 先看free -g，内存还剩余60多GB，排除内存不足。再查dmesg，关键信息是Out of memory: Kill process ... (tidb-server) score 0 or sacrifice child，再往上翻几行，看到vm.max_map_count = 65530 exceeded。这才想起来分布式数据库的内存映射非常密集，每个分片、每个Raft日志文件都要mmap。

根因： 默认的vm.max_map_count=65530对于分布式数据库来说太小了。

解决：

bash复制sysctl -w vm.max_map_count=1048576

同时把设置写入/etc/sysctl.conf让重启后依然生效。

经验： 这是分布式数据库部署中最容易踩的坑。你以为OOM就是内存不够，实际是内核限制了mmap数量。建议所有节点启动前就把它调大。

6.3 坑三：连接风暴——应用连接池配置不当导致计算节点假死

现象： 压测线程从64增加到128时，计算节点出现"连接拒绝"错误，甚至整个节点响应变慢，但CPU和内存都很健康。

排查链路： 看计算节点日志，看到大量too many open files错误，再查ss -lnt，连接数达到8000多。原因是应用测试脚本用了不合理的连接池配置——每压测线程创建两个连接，128线程就是256个连接，但连接池最小空闲连接数设成了50，一个压测线程池实际创建了500个连接。

根因： 不是数据库的坑，是压测客户端本身设计不合理，创建的连接远超实际需求。连接数暴增后，计算节点的连接管理线程成为瓶颈。

解决： 重新设计压测脚本，连接池最大连接数限制为线程数的1.5倍，最小空闲连接数设为10。同时对计算节点max-connections做了限制，从默认值调整到3000，避免无穷连接打垮节点。

经验： 生产环境一定要在数据库层面对最大连接数做限制，不要给应用无限连接的权限。等到连接风暴发生后再处理，数据库早就被拖垮了。

6.4 复盘：这三个坑的共同特征

这三个坑有一个共同特征：**都不是OpenTeleDB本身的逻辑问题，而是部署环境准备不充分或者使用方式不当。**分布式数据库对运行环境的要求比单机数据库严格得多，这也是我写这篇实录最想强调的——分布式数据库部署的复杂度不在"安装"这一步，而在环境治理和应用适配。

好在这些坑都有成熟的解决方案，花半天时间把系统参数准备好，后面会省非常多的时间。

7. 这次部署验证出的核心优势，以及适用边界

7.1 真正打动我的四个优势

经过这次完整的部署和压测，OpenTeleDB在OLTP场景的核心优势我用一句话概括：它把"扩展数据库"这个动作从"伤筋动骨"变成了"常态操作"。

具体体现在四个方面：

第一，弹性扩展是真的动态。 我在压测到一半时向集群添加了一个存储节点，大概2分钟左右，调度中心自动开始把部分分片的数据迁移到新节点，整个过程中读写完全没中断。对一个经历过"业务要扩容，DBA熬夜分库"的人来说，这种体验有多爽，不用我多说吧？

第二，故障转移不需要人肉巡检。 测试时直接kill掉一个存储节点，几十秒后该节点上的Leader自动切换到其他节点，应用的写入只经历了极短的不可用窗口。单机MySQL的主从切换需要人工介入，甚至需要停写才能保证数据一致，这里完全是自动化的。

第三，兼容MySQL协议迁移成本低。 业务代码基本不需要改，连接串从MySQL地址换成计算节点地址，剩下的交给数据库。对存量业务来说，这是选择分布式数据库的核心决策点——如果方案要求业务代码大面积改造，那它性能再好也上不了线。

第四，分布式事务对业务透明。 我在压测时专门写了个跨分片转账的测试场景，在OpenTeleDB上跑和单机MySQL一样，不需要业务方处理分布式事务的补偿逻辑，这对业务开发来说是非常大的解放。

7.2 适用边界：不是银弹，别指望它什么都干

说到边界，有几点必须坦诚：

它不适合超大规模的分析查询。OLAP场景的复杂Join、全表扫描、大宽表聚合，这是ClickHouse这类分析型数据库的活。OpenTeleDB在OLAP场景下虽然能跑，但不是最优解。
简单的KV场景用它太重了。如果业务就是简单的Set/Get，Redis或者TiKV这类KV数据库更合适，没必要上完整的SQL层。
强一致性对性能有影响。如果业务允许最终一致性，纯异步复制的方案在写入性能上会更好。OpenTeleDB默认三副本强一致写入，在跨机房部署时会放大网络延迟的影响。

7.3 和"分库分表中间件"方案的一个关键对比

很多团队在评估分布式方案时都会对比"分库分表中间件+单机MySQL"的路线。我这次顺便把这个对比维度也整理了：

维度	分库分表中间件	OpenTeleDB
业务代码改动	需要，分片键要业务指定	基本不用，透明分片
扩容方式	预分片，扩容要迁移数据	动态分裂合并，加节点即可
分布式事务	业务自己补偿	内置，对上层透明
故障转移	依赖MySQL主从，人工介入	自动选主
运维复杂度	中间件+多套MySQL混合运维	一套集群统一运维

单从性能数字看，分库分表在极端调优后可能和OpenTeleDB差距不大，但算上运维和人力的长期成本，分布式数据库的TCO优势非常明显。

7.4 什么场景下值得你引入

根据这次部署经验，我总结出三个值得引入OpenTeleDB的信号：

单机MySQL的CPU或IO已经到70%以上，并且你用尽了SQL优化、参数调优等手段依然无法压下去。
业务的读写比没有极端偏移，写入同样占了相当比例，主从复制方案已经明显感觉到写瓶颈。
未来半年到一年有明确的业务增长预期，你不想在每次大促前都做一次"扩容评估"。

反之，如果数据量很小（单表百万行以内）、QPS长期在几千以下、团队也没有专职DBA，那继续用单机MySQL，把预算花在SQL优化和硬件升级上，反而是更务实的选择。

8. 最后：部署过程中的几点真实体会，以及一个小建议

这次OpenTeleDB部署让我最有收获的不是性能数据本身，而是逼着我重新梳理了一遍对OLTP架构的理解。**单机数据库的性能瓶颈，从来不是靠"更贵的机器"就能突破的，架构层面的分而治之才是解决之道。**如果你也在面对OLTP性能瓶颈，我建议先做一次彻底的瓶颈画像：CPU打满还是IO打满？读瓶颈还是写瓶颈？并发上去延迟是线性上升还是指数上升？搞清楚这几点，再决定是继续优化单机、上分库分表，还是直接评估OpenTeleDB一类的分布式数据库。

最后再分享一个小技巧：**压测调优时保留一份原始配置的备份，每次只改一个参数变量。**我见过太多人一次性改五个参数，结果性能异常时根本分不清是哪个参数的问题。参数调优最忌讳的就是"三心二意"，一次只改一个，压测一轮，记下结果，再改下一个。这条规则朴素，但能帮你省掉大量排查问题的时间。