给大家看一个我使用 OpenClaw 管控 TiDB 的实操过程,主要是让大家看到当前AI数据库管控能力的强大,这个只是通过自然语言的交互让 OpenClaw 帮忙部署和测试了一套最小规模的 TiDB 集群,验证了 TiDB 数据库作为一个开发人员的开发环境数据库来使用时性能完全足够,关于如何安装 OpenClaw 可以参考我的微信公众号:晓磊聊DB,里面有一篇《从零搭建智能办公助手:OpenClaw + DeepSeek + Slack 完整指南》 。需要强调的是:OpenClaw操作数据库有风险,本次的所有操作都是自己云服务器环境,非线上和测试环境(我给的权限比较高,禁止在公司线上和测试环境使用OpenClaw管控TiDB集群,删库跑路你懂的,😂)。
打开openclaw tui命令行工具
(一)命令行输入:帮我安装一个tidb的部署工具tiup,并且使用tiup playground拉起一个最小规模的tidb集群。
🎯 任务完成总结
✅ 已完成的部分:
- TiUP 安装成功 - 版本 1.16.4,已添加到 PATH
- PD 组件下载完成 - 版本 v8.5.5
- TiDB 集群启动进程已开始 - 正在后台运行
🔄 进行中的部分:
- TiKV 组件下载中 - 375MB,当前进度约 14%,预计还需 4-5 分钟
- 下载完成后会自动启动 TiDB 和 TiKV 组件
📊 集群配置:
- TiDB 节点: 1个
- TiKV 节点: 1个
- PD 节点: 1个
- TiFlash 节点: 0个(禁用)
- 监控: 已禁用(--without-monitor)
- 版本: v8.5.5(最新稳定版)
🔧 如何使用 TiDB 集群
当集群启动完成后(您会看到类似下面的输出):
CLUSTER START SUCCESSFULLY, Enjoy it ^-^
To connect TiDB: mysql --comments --host 127.0.0.1 --port 4000 -u root
常用命令:
- 连接到 TiDB:
mysql -h 127.0.0.1 -P 4000 -u root
- 检查集群状态:
export PATH=$PATH:/root/.tiup/bin
tiup playground display
- 停止集群:
# 在 playground 终端中按 Ctrl+C
# 或使用 tiup 命令
tiup playground scale-in --all
- 查看运行中的实例:
tiup status
⏳ 当前状态监控
集群启动进程正在后台运行(session ID: faint-shoal)。您可以通过以下方式监控进度:
# 查看进程日志
process poll --sessionId faint-shoal
# 查看进程列表
process list
🚀 下一步操作建议
- 等待下载完成 - TiKV 组件下载完成后,集群会自动启动
- 验证连接 - 使用 mysql -h 127.0.0.1 -P 4000 -u root 测试连接
- 测试功能 - 创建数据库、表,插入数据测试 TiDB 功能
注意:TiUP playground 启动的集群是临时的,适合开发和测试。生产环境请使用 tiup cluster 命令部署。
需要我继续监控集群启动状态,还是您想了解其他 TiDB/TiUP 相关功能?
(二)命令行输入:帮我查看下tidb集群的启动状态
很好!TiDB Dashboard 重定向正常。现在让我为您总结 TiDB 集群的启动状态:
📊 TiDB 集群启动状态报告
✅ 集群启动完成!
启动时间: 2026-03-03 14:01 (GMT+8) 集群ID: VCmTkw4 版本: TiDB v8.5.5
🔧 集群组件状态
┌──────┬───────────┬─────────┬─────────────┬───────────────────────┐ │ 组件 │ 状态 │ PID │ 监听端口 │ 健康状态 │ ├──────┼───────────┼─────────┼─────────────┼───────────────────────┤ │ PD │ ✅ 运行中 │ 3690941 │ 2379/2380 │ 健康 (Leader: pd-0) │ ├──────┼───────────┼─────────┼─────────────┼───────────────────────┤ │ TiKV │ ✅ 运行中 │ 3693868 │ 20160/20180 │ 健康 (Metrics 可访问) │ ├──────┼───────────┼─────────┼─────────────┼───────────────────────┤ │ TiDB │ ✅ 运行中 │ 3694556 │ 4000/10080 │ 健康 (可连接) │ └──────┴───────────┴─────────┴─────────────┴───────────────────────┘
🌐 访问信息
- TiDB 数据库连接:
mysql -h 127.0.0.1 -P 4000 -u root
- TiDB Dashboard (Web UI):
http://127.0.0.1:2379/dashboard
- PD API:
http://127.0.0.1:2379/pd/api/v1/...
📈 集群配置
- 拓扑: 1 TiDB + 1 TiKV + 1 PD (最小规模)
- 存储引擎: TiKV
- 监控: 已禁用 (--without-monitor)
- 数据目录: /root/.tiup/data/VCmTkw4/
🔍 健康检查结果
- PD 集群状态: ✅ 正常 (1个成员,已选举 Leader)
- TiKV 存储状态: ✅ 正常 (Metrics 端点可访问)
- TiDB SQL 层: ✅ 正常 (可连接并执行查询)
- 组件版本一致性: ✅ 一致 (全部为 v8.5.5)
💡 快速测试
已成功执行以下测试:
- ✅ 连接 TiDB: SELECT VERSION() → 8.0.11-TiDB-v8.5.5
- ✅ 查看数据库: SHOW DATABASES → 显示默认数据库
- ✅ PD API 访问: 集群信息可获取
- ✅ TiKV Metrics: 监控数据可访问
⚡ 下一步操作建议
- 测试数据库操作:
CREATE DATABASE test_db;
USE test_db;
CREATE TABLE test_table (id INT PRIMARY KEY, name VARCHAR(50));
INSERT INTO test_table VALUES (1, 'test');
SELECT * FROM test_table;
- 查看集群信息:
SELECT * FROM information_schema.cluster_info;
SELECT * FROM information_schema.cluster_confi g;
- 性能测试 (可选):
# 使用 sysbench 进行基准测试
tiup bench tpcc --host 127.0.0.1 --port 4000 --user root --warehouses 1 prepare
tiup bench tpcc --host 127.0.0.1 --port 4000 --user root --warehouses 1 run
🛑 停止集群
当您完成测试后,可以通过以下方式停止集群:
- 在 playground 终端按 Ctrl+C
- 或使用命令: tiup playground scale-in --all
集群现在已完全启动并运行正常! 🎉 您可以开始使用 TiDB 进行开发和测试了。
(三)命令行输入:好的,你帮我修改下tidb集群的root数据库用户的密码为ah........lhth,然后创建一个新的dbadmin的数据库用户,并且配置同样的密码,这个dbadmin的用户权限是all。
✅ TiDB 用户配置完成
📋 执行结果总结
- root 用户密码修改:
- ✅ 成功修改 root@% 用户密码
- 新密码: ah.....h
- 验证: 使用新密码连接成功
- dbadmin 用户创建:
- ✅ 成功创建 dbadmin@% 用户
- 密码: ahl....... h (与 root 相同)
- 权限: ALL PRIVILEGES ON . WITH GRANT OPTION
- 权限验证:
- ✅ dbadmin 用户可连接数据库
- ✅ dbadmin 用户拥有完整权限(创建/删除数据库、表等)
- ✅ root 用户新密码正常工作
🔐 用户账户信息
┌─────────┬──────┬───────────────────────────────────┬─────────────────────────────┐ │ 用户名 │ 主机 │ 密码 │ 权限 │ ├─────────┼──────┼───────────────────────────────────┼─────────────────────────────┤ │ root │ % │ ahl。。。。。 h │ 默认 root 权限 │ ├─────────┼──────┼───────────────────────────────────┼─────────────────────────────┤ │ dbadmin │ % │ ahl。。。。 h │ GRANT ALL PRIVILEGES ON . │ └─────────┴──────┴───────────────────────────────────┴─────────────────────────────┘
🔧 连接示例
使用 root 用户连接:
mysql -h 127.0.0.1 -P 4000 -u root -pahl.....th
使用 dbadmin 用户连接:
mysql -h 127.0.0.1 -P 4000 -u dbadmin -pahl....th
📝 已执行的 SQL 命令
-- 修改 root 用户密码
ALTER USER 'root'@'%' IDENTIFIED BY 'ahl..... h';
-- 创建 dbadmin 用户
CREATE USER 'dbadmin'@'%' IDENTIFIED BY 'ahl.....h';
-- 授予 dbadmin 所有权限
GRANT ALL PRIVILEGES ON *.* TO 'dbadmin'@'%' WITH GRANT OPTION;
-- 刷新权限
FLUSH PRIVILEGES;
✅ 验证测试
- 密码验证: ✅ 两个用户均可使用新密码连接
- 权限验证: ✅ dbadmin 用户拥有完整数据库操作权限
- 功能验证: ✅ 两个用户均可创建/删除数据库和表
⚠️ 安全建议
- 密码安全: 当前密码较为复杂,建议定期更换
- 访问控制: 考虑将 % 通配符替换为具体的 IP 地址范围
- 权限管理: dbadmin 拥有完整权限,建议根据实际需要细化权限
- 连接安全: 生产环境建议启用 SSL/TLS 加密连接
所有用户配置任务已完成,TiDB 集群现在有两个具有相同密码的管理员账户:root 和 dbadmin,其中 dbadmin 拥有完整的数据库权限。
(四)命令行输入:帮我对这个tidb集群进行简单的压力测试,并且给出压力测试报告,请使用dbadmin账号来进行测试。
现在让我生成压力测试报告:
📊 TiDB 集群压力测试报告
🔧 测试环境配置
┌───────────┬─────────────────────────────────────┐ │ 项目 │ 配置 │ ├───────────┼─────────────────────────────────────┤ │ TiDB 版本 │ v8.5.5 │ ├───────────┼─────────────────────────────────────┤ │ 集群规模 │ 1 TiDB + 1 TiKV + 1 PD │ ├───────────┼─────────────────────────────────────┤ │ 测试用户 │ dbadmin │ ├───────────┼─────────────────────────────────────┤ │ 测试工具 │ sysbench 1.0.20 │ ├───────────┼─────────────────────────────────────┤ │ 测试时长 │ 每个测试 60 秒 │ ├───────────┼─────────────────────────────────────┤ │ 并发线程 │ 8 线程 │ ├───────────┼─────────────────────────────────────┤ │ 数据规模 │ 10 个表 × 10,000 行/表 = 100,000 行 │ ├───────────┼─────────────────────────────────────┤ │ 测试时间 │ 2026-03-03 14:11-14:20 (GMT+8) │ └───────────┴─────────────────────────────────────┘
📈 性能测试结果
1. OLTP 只读测试 (oltp_read_only)
┌──────────┬────────────┬────────────────────┐ │ 指标 │ 结果 │ 说明 │ ├──────────┼────────────┼────────────────────┤ │ TPS │ 183.11/s │ 每秒事务数 │ ├──────────┼────────────┼────────────────────┤ │ QPS │ 2,929.83/s │ 每秒查询数 │ ├──────────┼────────────┼────────────────────┤ │ 读取 QPS │ 2,564.38/s │ 每秒读取查询数 │ ├──────────┼────────────┼────────────────────┤ │ 95% 延迟 │ 59.99ms │ 95% 请求的响应时间 │ ├──────────┼────────────┼────────────────────┤ │ 平均延迟 │ 43.67ms │ 平均响应时间 │ ├──────────┼────────────┼────────────────────┤ │ 最大延迟 │ 1,937.21ms │ 最大响应时间 │ ├──────────┼────────────┼────────────────────┤ │ 错误率 │ 0.00% │ 无错误 │ └──────────┴────────────┴────────────────────┘
2. OLTP 只写测试 (oltp_write_only)
┌──────────┬────────────┬────────────────────┐ │ 指标 │ 结果 │ 说明 │ ├──────────┼────────────┼────────────────────┤ │ TPS │ 292.16/s │ 每秒事务数 │ ├──────────┼────────────┼────────────────────┤ │ QPS │ 1,752.96/s │ 每秒查询数 │ ├──────────┼────────────┼────────────────────┤ │ 写入 QPS │ 1,169.25/s │ 每秒写入查询数 │ ├──────────┼────────────┼────────────────────┤ │ 95% 延迟 │ 42.61ms │ 95% 请求的响应时间 │ ├──────────┼────────────┼────────────────────┤ │ 平均延迟 │ 27.37ms │ 平均响应时间 │ ├──────────┼────────────┼────────────────────┤ │ 最大延迟 │ 148.36ms │ 最大响应时间 │ ├──────────┼────────────┼────────────────────┤ │ 错误率 │ 0.00% │ 无错误 │ └──────────┴────────────┴────────────────────┘
3. OLTP 混合读写测试 (oltp_read_write)
┌──────────┬────────────┬──────────────────────┐ │ 指标 │ 结果 │ 说明 │ ├──────────┼────────────┼──────────────────────┤ │ TPS │ 99.72/s │ 每秒事务数 │ ├──────────┼────────────┼──────────────────────┤ │ QPS │ 1,994.63/s │ 每秒查询数 │ ├──────────┼────────────┼──────────────────────┤ │ 读取 QPS │ 1,396.20/s │ 每秒读取查询数 │ ├──────────┼────────────┼──────────────────────┤ │ 写入 QPS │ 399.82/s │ 每秒写入查询数 │ ├──────────┼────────────┼──────────────────────┤ │ 95% 延迟 │ 108.68ms │ 95% 请求的响应时间 │ ├──────────┼────────────┼──────────────────────┤ │ 平均延迟 │ 80.14ms │ 平均响应时间 │ ├──────────┼────────────┼──────────────────────┤ │ 最大延迟 │ 228.67ms │ 最大响应时间 │ ├──────────┼────────────┼──────────────────────┤ │ 错误率 │ 0.02% │ 极低错误率 (1个错误) │ └──────────┴────────────┴──────────────────────┘
📊 性能对比分析
| 测试类型 | TPS | QPS | 95% 延迟 | 特点 | |----------|-----|-----|-------- --|------| | 只读 | 183.11/s | 2,929.83/s | 59.99ms | 读取性能优秀,QPS 最高 | | 只写 | 292.16/s | 1,752.96/s | 42.61ms | 写入性能最佳,延迟最低 | | 混合 | 99.72/s | 1,994.63/s | 108.68ms | 综合性能平衡,延迟较高 |
💾 资源使用情况
内存使用 (测试后)
- 总内存: 7.7 GB
- 已使用: 6.7 GB (86.8%)
- TiKV 内存: ~2.0 GB (25.3% of total)
- TiDB 内存: ~0.75 GB (9.7% of total)
- PD 内存: ~0.1 GB (1.3% of total)
CPU 使用 (测试后)
- TiKV CPU: 15.7%
- TiDB CPU: 19.4%
- PD CPU: 2.3%
集群状态
- 运行时间: 23 分钟 54 秒
- 所有组件: 运行正常
- 连接: 无重连,稳定性良好
📋 测试结论
✅ 优势
- 写入性能优秀: 只写测试 TPS 达到 292.16/s,延迟仅 42.61ms
- 读取性能良好: 只读测试 QPS 达到 2,929.83/s
- 稳定性高: 测试期间无连接中断,错误率极低
- 资源利用合理: 内存和 CPU 使用在正常范围内
- 响应时间可控: 95% 请求延迟在可接受范围内
⚠️ 注意事项
- 混合负载延迟较高: 混合读写测试延迟达到 108.68ms,建议优化
- 内存使用较高: TiKV 使用了 2GB 内存,对于小规模测试偏高
- 无交换空间: 系统未配置交换空间,可能影响极端情况下的稳定性
🔧 优化建议
- TiKV 配置优化:
- 调整 block-cache-size 减少内存使用
- 优化 raftstore 相关参数提高写入性能
- TiDB 配置优化:
- 调整 tidb_mem_quota_query 控制查询内存
- 优化 tidb_executor_concurrency 提高并发处理能力
- 测试环境优化:
- 增加测试数据量 (100万行以上) 获得更准确结果
- 延长测试时间 (300秒以上) 观察稳定性
- 增加并发线程数 (16-32线程) 测试极限性能
🎯 总体评价
评分: 8.5/10
这个最小规模的 TiDB 集群在压力测试中表现良好,特别是在写入性能方面表现出色。对于开发 和测试环境来说,性能完全足够。主要瓶颈出现在混合读写场景,这是分 布式数据库的常见挑战。
适用场景:
- ✅ 开发测试环境
- ✅ 中小型应用原型
- ✅ 学习和技术验证
- ⚠️ 生产环境需要更大规模集群和优化配置
测试完成,所有测试数据已清理,集群状态正常。