「 TDSQL 是腾讯云的分布式 MySQL，分库分表对应用基本透明，但"透明"不等于"随便写"。很多慢，根子都在分片键没选对、读写分离没生效、监控看错了指标。下面这 6 招按"设计 → 路由 → 管理 → 计划 → 监控 → 恢复"的顺序来，照着敲就行。这几处也正是分布式数据库方向认证考试里实操常考的部分，不少运维就栽在读写分离没加 -c 上。 」
一、分片键命中：别让一条 SQL 跑遍所有分片
▲ 架构/流程要点图（对照正文）
建表时 shardkey 就定死了，后面 ALTER TABLE 改不了；主键和唯一索引必须包含分片键（广播表除外），否则唯一性校验要跨节点，慢且容易出错。分片键选高基数列、且查询常带条件的列，避免不带条件时全分片广播扫描。
|--------------|------------------------------------|------------|
| 要点 | 做法 | 说明 |
| 建表定 shardkey | CREATE TABLE ... shardkey=order_id | 建表时定，之后改不了 |
| 主键含分片键 | 主键列包含 shardkey | 否则唯一校验跨节点 |
| 避免广播 | WHERE 带 shardkey 条件 | 不带则全分片扫描 |
「 经验：选错分片键，后面所有查询都背着"跨节点汇总"的包袱，设计时多花十分钟，省下后面无数次排障。考证里也常拿"分片键选错导致全表扫"当案例。 」
二、读写分离路由：`/*slave*/` 必须加 `-c`
读写分离靠 hint /*slave*/ 把读请求路由到备节点。但 MySQL 系客户端默认会剥掉 SQL 注释（含 hint），不加 -c 就连同 hint 一起被过滤掉，读写分离静默失效、读全打主库。注意 /*slave*/ 只对 SELECT 生效，写永远走主。
/*slave*/ SELECT * FROM orders WHERE user_id = 123;
|-------------------|-------------------------------------------|
| 场景 | 要点 |
| 连接客户端 | mysql -c -h proxy -P 3306 -u ...（-c 保留注释） |
| 自动读写分离 rw_split=2 | 事务内读也走主，出事务才按 hint 走备（不是 hint 失效） |
| 只对 SELECT 生效 | 写语句别指望走备 |
三、代理管理命令：`/*proxy*/` 只用于 3 条
/*proxy*/ 是发给代理层（不是存储节点）的命令，只适用于 help / show config / show status 三条。show processlist / kill <id> / EXPLAIN 都不加前缀直接执行，EXPLAIN 会自动追一列信息，无需任何前缀。
|-----------------------------------|---------------------|
| 命令 | 是否加 /*proxy*/ |
| help / show config / show status | 加 |
| show processlist / kill / EXPLAIN | 不加 |
「 坑点：把 /*proxy*/ 套到 kill 或 EXPLAIN 上，命令要么跑不到代理层、要么计划信息不对，排障时别乱加前缀。 」
四、执行计划与索引：EXPLAIN 看是不是走了分片键
慢查询先 EXPLAIN，确认计划是否命中 shardkey（单分片扫描还是全分片）。跨分片聚合（不带分片键的 GROUP BY / ORDER BY）会下推各分片再汇总，特别慢。频繁按非分片键查，考虑建全局索引。
EXPLAIN SELECT * FROM orders WHERE user_id = 123;
|---------|---------------------|
| 看什么 | 说明 |
| 是否单分片 | 全分片扫描 = 分片键没命中 |
| 跨分片聚合 | 下推各分片再汇总，慢 |
| 全局索引 | 非分片键高频查，用全局索引避免全分区扫 |
五、监控看 Threads_running，不是 Threads_connected
Threads_connected 高只代表连得多，不代表忙；真正卡顿看 Threads_running（正在跑的线程数）。实例雪崩时，盯 Threads_running 是否持续打高，比看连接数有用得多。
SHOW GLOBAL STATUS LIKE 'Threads_running';
SHOW GLOBAL STATUS LIKE 'Threads_connected';
「 经验值：Threads_running 长期贴近 max_connections 的七成以上，基本就是在堵了，先查慢 SQL 而不是盲目加连接。 」
六、PITR 时间点恢复：克隆新实例，不碰原库
TDSQL 的 PITR 不直接回滚原实例（避免二次伤害），而是克隆一个新实例恢复到指定时间点，再从新实例把数据抽回原库或新业务库。误删表第一时间保留现场，走控制台或 API 发起 PITR 克隆，别在原实例上直接恢复。
|---------|---------------------|
| 步骤 | 做法 |
| 保留现场 | 误操作后先别动原实例 |
| 发起 PITR | 控制台/API 克隆新实例到指定时间点 |
| 抽数导回 | 从新实例把数据导回原库或新库 |
▲ 一图速查：核心要点汇总（建议收藏）
小结
分片键定死 → 读写分离加 -c → 代理命令认准 3 条 → EXPLAIN 看分片命中 → 监控盯 Threads_running → PITR 走克隆。这 6 招覆盖 TDSQL 日常八成的性能与排障现场，存下来，下次值班直接照着走。把这套链路练熟，不管是日常排障还是考证实操都够用。
------ 本文由云贝教育整理出品