写这篇东西的时候，我刚把 TiDB 装到一台测试机器上。说实话，每次装数据库我都觉得像在拆盲盒——要么顺风顺水，要么踩坑踩到怀疑人生。TiDB 这玩意儿，号称是分布式数据库里的“新物种”，但安装起来并没有那么玄乎。只需要一台 Linux 机器，别太老旧，CentOS 7 或者 Ubuntu 18.04 以上都可以。要是手头有台 8 核 16 GB 的服务器，那简直算豪华配置。不过别担心，就算只有 4 核 8 GB，也能跑起来，只是别指望它能扛住双十一的流量。
先说说准备工作。安装 TiDB 最核心的组件叫 TiUP，这玩意儿就像瑞士军刀，装什么、升级什么、监控什么全靠它。下载 TiUP 的命令只有一行：。别被这长串吓到，实际上就是个脚本，跑完会自动配置环境变量。若你使用的是 root 用户，记得改下权限，不然后面会报错。我当初就是栽在这上面，配完环境变量忘了 ，结果敲 命令时系统一脸懵逼，害我排查了半天。
接下来就是安装 TiDB 集群。用 TiUP 装集群，本质上是写个拓扑文件，告诉它有几台机器、每台机器跑什么角色。比如只有一台机器，拓扑文件就写一个节点，把 PD、TiKV、TiDB 这些组件全塞进去。若有三台机器，就可以更精细地分配。写拓扑文件时有个小技巧：TiKV 的内存千万别太抠，至少留 4 GB，不然在写入压力大时会卡得像老牛拉破车。我见过有人只给 TiKV 配了 1 GB 内存，结果一压测就直接 OOM，日志里全是 “out of memory” 的惨叫。
拓扑文件写好后，执行 命令，系统会自动下载组件、创建目录、启动服务。这一步最怕网络不稳定，因为要拉好几个 GB 的包。我上次装的时候，公司网络抽风，下载到一半断了，TiUP 报了个 “context deadline exceeded” 的错误。解决办法也简单：换个时间段再试，或者使用代理。实在不行，去 PingCAP 官网把离线包下载下来，解压后安装，省得跟网速较劲。
装完不等于万事大吉。要检查服务状态，用 看所有节点是否健康。若发现某个 TiKV 节点显示 “Down”，别慌，先看看日志。日志路径默认在 ，或者在拓扑文件里指定的目录。常见问题大多是端口被占、磁盘空间不足、或者系统参数没调好。比如 Linux 的 和 没改，TiKV 写入时会频繁触发磁盘刷写，性能直接打三折。修改方法也简单：在 加上几行配置，然后 生效即可。
真正让人头疼的是网络配置。TiDB 是分布式系统，节点之间靠 gRPC 通信。如果在云上装，安全组或防火墙一定要放通几个关键端口：PD 的 2379、2380，TiKV 的 20160，TiDB 的 4000。我有个朋友在公司内网装，防火墙策略一直没调通，PD 始终连不上 TiKV，折腾了两天才发现是某条 iptables 规则把包过滤了。后来他索性 关了防火墙，瞬间一切正常。当然，生产环境不能这么干，需要写精确的放行规则。
装完之后，用 MySQL 客户端连上去试试。端口是 4000，默认用户是 root，密码为空。敲 能看到系统库就说明成功。这时候你可能会想，就这么简单？对，就是简单。但简单不代表没有坑。比如 TiDB 默认时区是 UTC，接业务系统时记得在配置文件里改成 ，否则时间戳会全乱套。另外，TiDB 的 SQL 兼容性虽高，但有些锁机制与 MySQL 不同，例如不支持外键，写复杂事务时需要注意逻辑。
说个玄学问题：磁盘性能。TiDB 对磁盘 IOPS 要求很高，尤其是 TiKV 节点。普通 HDD 装上去，写入延迟动不动就上 200 ms，查询慢得像蜗牛。最好使用 SSD，哪怕是入门级的 SATA SSD，体验也比 HDD 好十倍。我见过有人用云硬盘，结果云厂商把 IOPS 限得死死的，一压测就爆延迟。解决办法是选高 IOPS 的云盘，或者本地 NVMe SSD。预算紧张时，至少给 TiKV 单独挂块盘，别和系统盘挤在一起。
装 TiDB 这事儿，说白了就是个 “配置+耐心” 的游戏。按文档一步步来，大概率不会出大问题。但万一碰到报错，别急着骂娘，先看日志，再查论坛。TiDB 社区很活跃，你踩过的坑大多数人也踩过。别像我当初那样，傻乎乎地重装了三次才发现是网络问题。记住：装数据库不是考试，错了可以重来，关键是学会看错误信息。等你装完跑起来，看到查询结果刷刷刷地出来，那种成就感，比打游戏通关还爽。
