TiDB单机部署全攻略：从环境准备到性能调优

一、单机部署的适用场景与核心优势

TiDB作为一款开源的分布式NewSQL数据库，其设计初衷是解决海量数据下的水平扩展问题。然而，在开发测试、个人学习或轻量级业务场景中，单机部署仍具有显著价值。核心优势体现在：

1. 资源占用可控：单机模式下仅需单节点资源，适合资源受限环境（如物理机、虚拟机或K8s Pod）。
2. 部署效率高：无需配置集群通信、分布式事务协调等复杂组件，安装流程简化。
3. 故障隔离简单：单节点故障仅影响本地服务，便于快速定位问题。

需注意，单机模式不推荐生产环境使用，因其无法发挥TiDB的分布式特性（如弹性扩展、高可用）。建议仅在以下场景使用：

• 开发阶段的功能验证
• 性能基准测试
• 离线数据分析任务

二、环境准备与依赖检查

1. 硬件配置要求

组件	最低配置	推荐配置
CPU	4核	8核+
内存	8GB	32GB+
磁盘	100GB SSD	500GB NVMe SSD
操作系统	Linux（内核≥3.10）	CentOS 7/8, Ubuntu 20.04

关键点：

• 磁盘I/O性能直接影响TiKV的存储效率，建议使用SSD而非HDD。
• 内存不足会导致OOM（Out of Memory）错误，需根据数据量调整mem-quota-query参数。

2. 软件依赖安装

# 示例：CentOS 7环境下的依赖安装
sudo yum install -y epel-release
sudo yum install -y wget curl git gcc make

依赖项说明：

• Numa：建议启用NUMA以优化内存访问（通过numactl --interleave=all启动服务）。
• Time Sync：需确保系统时间同步（ntpdate或chronyd），避免时钟漂移导致事务错误。

三、单机部署详细步骤

1. 下载并解压安装包

wget https://download.pingcap.org/tidb-latest-linux-amd64.tar.gz
tar -xzvf tidb-latest-linux-amd64.tar.gz
cd tidb-latest-linux-amd64

2. 配置文件调整

编辑conf/tidb.toml，关键参数如下：

[performance]
max-procs = 8  # 绑定CPU核心数
[tikv]
rocksdb.max-background-jobs = 4  # RocksDB后台任务数
[pd]
enable-grpc-gateway = false  # 单机模式禁用PD的gRPC网关

参数优化建议：

• 若内存≥32GB，可设置mem-quota-query = 8589934592（8GB）以避免查询内存不足。
• 关闭telemetry（enable-telemetry = false）以减少非必要日志。

3. 启动服务

# 启动TiDB服务（后台运行）
nohup ./bin/tidb-server -config conf/tidb.toml -store tikv -path /data/tidb > tidb.log 2>&1 &
# 启动TiKV服务
nohup ./bin/tikv-server --addr "0.0.0.0:20160" --status-addr "0.0.0.0:20180" \
--data-dir "/data/tikv" --pd "127.0.0.1:2379" > tikv.log 2>&1 &

验证启动状态：

# 检查TiDB端口（默认4000）
netstat -tulnp | grep 4000
# 通过MySQL客户端连接
mysql -h 127.0.0.1 -P 4000 -u root

四、性能调优与监控

1. 关键指标监控

使用Prometheus + Grafana监控单机性能：

# 启动Prometheus（需提前下载配置文件）
nohup ./bin/prometheus --config.file=prometheus.yml > prometheus.log 2>&1 &

核心指标：

• QPS/TPS：通过tidb_server_query_total计量。
• 存储延迟：tikv_storage_async_request_duration_seconds。
• 内存使用：process_resident_memory_bytes。

2. 调优策略

• 内存分配：若出现OOM kill，调整/etc/security/limits.conf中的memlock限制。
• 日志级别：开发环境可设置为debug（log-level = debug），生产环境建议warn。
• 并发控制：通过tidb_distsql_scan_concurrency限制扫描并发数，避免I/O过载。

五、常见问题与解决方案

1. 启动失败：端口冲突

现象：Error: listen tcp 0.0.0.0 bind: address already in use
解决：

# 查找占用端口的进程
lsof -i :4000
# 终止进程或修改TiDB端口

2. 查询超时：ERROR 1105 (HY000): timeout

原因：单机模式下资源竞争导致。
优化：

• 增大tidb_server_max_procs。
• 调整tidb_distsql_scan_concurrency（默认15，建议降至8）。

3. 数据持久化问题

风险：单机模式无副本，数据仅存储在本地。
建议：

• 定期备份数据（mysqldump -h 127.0.0.1 -P 4000 -u root > backup.sql）。
• 测试环境可启用tikv_enable_atomic_write（实验性功能，需谨慎）。

六、总结与扩展建议

TiDB单机部署虽非生产级方案，但其在开发测试中的价值不可忽视。通过合理配置参数和监控指标，可实现高效稳定的本地运行环境。扩展建议：

• 后续可平滑迁移至集群模式（通过tiup cluster deploy命令）。
• 结合Sysbench进行基准测试，对比单机与集群的性能差异。

通过本文的指导，开发者能够快速完成TiDB单机部署，并为后续的分布式架构升级奠定基础。