「 腾讯云 TDSQL（MySQL 版）是在 MySQL 上做了分布式改造，很多同学拿单机 MySQL 的经验直接套，结果路由、读写分离、分片各种踩坑。这篇把最容易被坑的 6 个场景拆开讲，命令都能直接复制，建议先收一份。 」

一、代理管理命令的 /*proxy*/ 只用于 3 条

▲ 架构图：Proxy 网关 + 分片 + 读写分离（对照正文）

TDSQL 走 Proxy 网关，有些管理命令要加 /*proxy*/ 前缀才转给 proxy 执行，但不是所有命令都加。

场景	命令
看 proxy 帮助	/*proxy*/help
看 proxy 配置	/*proxy*/show config
看 proxy 状态	/*proxy*/show status

坑点：/*proxy*/ 只用于 `help` / `show config` / `show status` 这 3 条。像 show processlist、kill <id>、EXPLAIN 都不加前缀——EXPLAIN 无需任何前缀，直接写就好。有人给 EXPLAIN 也加 /*proxy*/，纯属多余还容易误导。

二、读写分离 hint 必须加 -c，否则静默失效

开了读写分离后，想让某条读走备库，要用 /*slave*/ hint。但客户端默认会剥离注释：

场景	命令
保留 hint 登录	mysql -c -h proxy_ip -P 3306 -u user -p
读走备库	SELECT /*slave*/ * FROM orders WHERE id=1;

坑点：/*slave*/ 必须加 -c 让客户端保留注释，否则被当注释过滤，读写分离静默失效——你以为读走备库了，其实全走主库，还查不出毛病。另外 /*slave*/ 只对 SELECT 生效，写永远走主，别指望拿它把写分流。

「 这块路由规则也是 TDSQL 分布式运维里常考的点，搞清楚 -c 和 hint 的关系能少踩很多坑。 」

三、分片键 shardkey 建表定死，ALTER TABLE 改不了

TDSQL 是分库分表，分片键是建表时定的：

场景	命令/规则
建表指定分片键	CREATE TABLE t (id int, ...) shardkey=id;
主键/唯一索引	必须包含分片键(广播表除外)
改分片键	ALTER TABLE ... 不支持，只能重建

坑点：shardkey 不支持用 `ALTER TABLE` 改，想换分片键只能重新建表导数据。而且主键和唯一索引必须包含分片键（广播表除外），否则建不了或路由异常。建表前一定把分片键选对。

四、自动读写分离：事务内读走主，不是 hint 失效

开了自动读写分离（rw_split=2）后，有个容易误判的点：

现象	真相
事务里查的数据走了主库	预期行为，不是 hint 失效
非事务的普通 SELECT	按读写分离策略走备库

坑点：自动读写分离（rw_split=2）下，事务内的读默认走主库，这是设计如此，不是你 /*slave*/ 失效。别一看到事务内读走主就以为分离坏了，先确认是不是在事务里。

五、监控盯 Threads_running，别只看连接数

看实例压力，连接数会骗人：

指标	含义
Threads_connected	当前连接总数(含空闲)
Threads_running	正在执行的并发数(真实压力)

坑点：Threads_connected 高不代表有压力——大量空闲连接也会计数。真正反映数据库忙不忙的是 Threads_running，监控和告警盯这个才准。

六、PITR 不直接改原实例，要克隆新实例导回

误删数据要回滚到某时间点，TDSQL 的 PITR 和单机 MySQL 不一样：

场景	做法
时间点恢复(PITR)	克隆一个新实例恢复到指定时间点
取回数据	从克隆实例抽数，导回原实例

坑点：TDSQL 的 PITR 不直接修改原实例，而是克隆一个新实例恢复到目标时间点，再从克隆实例把数据抽出来导回原库。别想着像单机 MySQL 那样原地闪回，那是两码事。

▲ 一图速查：核心规则汇总（建议收藏）

小结

TDSQL（MySQL 版）运维记住几条：**代理管理命令 /*proxy*/ 只用于 help/show config/show status；读写分离 /*slave*/ 必须加 -c 且只对 SELECT 生效；分片键建表定死、ALTER TABLE 改不了；事务内读走主不是 hint 失效；监控盯 Threads_running；PITR 克隆新实例导回**。命令都在上表，出问题照着敲基本能救。

想系统把分布式 MySQL（TDSQL）吃透，官方文档配合认证体系走一遍，体系会比零散搜博客稳很多。先收藏，省得真出事现找。