2.2 实例购买、账号权限与连接管理

买云数据库比买 CVM 简单，但有几个选择会直接影响后续使用体验：实例规格、可用性版本、账号划分、连接方式。这篇记一下我当时的决策过程和踩过的坑，所有选择都围绕一个坚定不移的原则——最小权限、最小暴露。这个原则和 1.3 里讲安全组时立下的规矩是同一套逻辑，只是换到了数据库领域。

一、买实例：三个关键选择

地域要和 CVM 一致。云数据库与 CVM 在同地域时走内网通信，延迟低、速度快，不消耗外网流量；跨地域就得走公网或者对等连接，性能和成本都不划算。我的应用服务器买在广州，数据库实例就跟着买广州地域，两者还必须在同一个私有网络里，内网才能直通——这个前提条件新手最容易忽略，买完发现连不上，排查半天才知道是网络不通。更细一层：可用区不必完全相同，但地域和私有网络必须一致，这是我操作前确认过文档的结论。

规格优先看内存。MySQL 是吃内存大户，InnoDB 缓冲池大小直接决定查询速度，而缓冲池受限于实例内存。我的图片社区数据量不大，入门的双核 4G 规格跑了很久，后来靠加索引和调参数（2.4 的内容）一直撑到日活上来才升级规格。经验是：CPU 影响并发与排序，内存影响缓存命中率，到了瓶颈优先升内存，而不是先升核数。怎么判断瓶颈在哪？看监控曲线：CPU 长期打满说明核数不够，缓存命中率低、IO 高说明内存不够。

计费方式按需选。和 CVM 一样，云数据库也分按量计费和包年包月。我的做法是项目初期用按量计费随时调整规格，跑稳定确认规格够用后，再切换成包年包月锁住成本——这样既不会被差价困扰，也不会为了便宜而一开始就绑死一个不确定的规格。选错规格最大的代价不是钱，是来回迁移数据的折腾。

前两个选择都还有试错空间：规格买小了可以升级，地域买错了顶多延迟高一点。但可用性版本一旦选定，再改就是相当折腾的事，所以这个决策值得多想五分钟。

版本选高可用还是基础，这是最重要的决策：

我的结论很直接：测试库用基础版无所谓，线上库必须高可用。多花的钱本质是给数据和持续服务买保险，这笔钱不能省——社区挂两小时，新用户可能就再也不回来了。切换的秒级到分钟级体验，是自建方案写多少脚本都难以稳定复现的。

顺带一个提醒：实例买完别急着导入数据，先在控制台确认实例状态为运行中、初始化账号已设置好，再开始建库建表，顺序乱了一样会踩无谓的坑。另外初始化账号的密码请第一时间保存到密码管理器里——实例创建时设置的密码丢了就只能重置，别问我怎么知道的。

二、账号权限：别让应用账号当超人

实例创建好，第一件事不是建表，而是想清楚账号怎么分。我给自己定的规矩是：应用账号绝不能拿到全实例权限，管理账号只在控制台由我本人使用，绝不写进代码配置或环境变量。这套规矩是吃过亏才立下的——早期我把带管理权限的账号配在代码里，某次代码仓库权限一开放，所有秘密就都成了明牌。

我的账号划分方案：

具体到权限粒度，应用账号和管理账号的差别是这样的：

规矩一句话：应用账号只会增删改查业务数据，凡是涉及结构和账号的操作，一律留给管理账号在控制台人工执行。

云数据库的账号管理支持库级粒度授权，每个账号只勾选需要的库和具体权限。操作上就是在控制台新建账号、设置一个强密码、然后勾选它能访问的库和权限，全程不用敲一行 SQL。这样安排的好处是实打实的：即使代码里哪天出了 SQL 注入漏洞，攻击面也被限制在单个库的增删改查范围内，不至于丢掉整个实例，更不会被顺手删掉别的库。

有一个容易漏的点：授权时只给真正用到的权限。DROP、ALTER 这类结构性变更权限，应用账号完全不需要；TRUNCATE 更是要从应用账号剔除——清表这种操作只应该由人在控制台做，不该出现在任何代码路径里。权限清单越短，出事的爆炸半径越小，这是我在自建时期用一次事故换来的教训。

密码管理也顺带说两句：应用账号的密码定期换，换密码时在控制台改一次、应用侧灰度滚动重启即可，不要把新旧密码同时留在配置里长期共存。实例详情页可以随时重置账号密码，操作成本极低，唯一的代价就是一次滚动重启——相比密码泄露的风险，这笔账划得来。重启时注意分批次来，别一次性把所有实例都断开，留下足够的服务能力兜底。

三、连接管理：内网和外网是两回事

云数据库提供两类连接地址，处理方式完全不同：

我的应用全程走内网地址，连接串里配的是实例详情页里的内网域名和 3306 端口，大致长这样：

# 应用里的数据库连接串（示意）
mysql://pic_app:你的密码@gz-cdb-xxxx.sql.tencentcdb.com:3306/pic_db

换实例的时候只改这一个配置项，代码一行都不用动——把连接信息统一收敛到配置中心，是后端的基本素养。从 CVM 上连数据库的命令也顺便放这儿，内网和外网各一条：

# 在同地域 CVM 上走内网连接（推荐，日常都用这条）
mysql -h gz-cdb-xxxx.sql.tencentcdb.com -P 3306 -u pic_app -p

# 应急走外网地址（端口以控制台开通时显示的为准，用完立刻关闭）
mysql -h gz-cdb-xxxx.sql.tencentcdb.com -P 外网端口 -u pic_app -p

外网地址默认不开放，我只有在出差应急排查时才临时开一会儿，用完马上关掉。数据库端口暴露在公网上被扫描是家常饭，各种自动化的碰撞尝试一刻不停，千万别让数据库裸奔。本质上，外网地址应该是应急通道，而不是常规连接方式——这条心态和我给安全组立的最小权限规矩（见 1.3）是一脉相承的。

连通性问题排查也有固定套路，按顺序三步走：先确认实例与 CVM 是否同地域同私有网络，再看安全组有没有放行数据库端口，最后检查账号主机权限和密码。多数问题死在第一步和第二步。更完整的排查清单可以看我另一本1Panel 常见问题，里头总结了服务连不上数据库的常见原因和验证命令。

如果你只是想快速把站跑起来，不想一上来就面对这些网络细节，可以让建站工具先帮你兜着，参考AI 建站实战，等业务起来再回来慢慢补这些课。

四、踩坑：连接数耗尽

上线后某天，应用突然大面积报错，日志里全是连接失败。我爬上控制台一看：实例的连接数监控已经顶到配额上限，新连接被直接拒绝。

原因是连接池配大了。应用起了多个 worker，每个 worker 都按网上抄来的配置开了几十个连接，叠加之后远超实例允许的连接数。云数据库的连接数配额与实例规格挂钩，规格越高允许的并发连接越多，超了就直接报错，业务侧的表现就是毫无征兆的批量超时。报错信息本身很有迷惑性，乍看像网络问题，其实是连接数问题——这个弯我绕了半小时。

连接数超限的几种表现和处理方式，我后来整理过一张速查表：

记住一点：连接数问题是典型的温水煮青蛙，平时不爆，高峰就要命。

我的处理分两步走：先把应用连接池的最大连接数调小，滚动重启把存量连接释放出来；随后评估长期方案，是升规格还是优化连接使用。怎么算池子该配多大？数一下应用一共有几个 worker，乘上每个 worker 的池上限，再留一半余量，和实例配额比一下就心里有数了。经验上连接池不是越大越好，超过配额反而引发雪崩，配在实例配额的一半以内比较稳妥；同时给连接数指标配上阈值告警，接近上限时提前收到通知，而不是等业务报错才知道。

事后我还做了一件收尾的事：把应用里所有直连数据库的地方集中到唯一一个数据访问层，连接池只在那一个地方初始化。之前散落在各处各自开连接的写法，正是连接数失控的温床——单看每段代码都很合理，叠在一起就超配额了。

日常写 SQL、查问题的时候，我常让 AI 帮忙先看一眼思路，效率高不少，工具链的实践见DeepSeek 工具链实战。尤其写复杂 JOIN 和窗口函数时，让 AI 先起草再人工审一遍，比自己从空白文档开始写要快两三倍。

五、小结

• 买实例：地域和网络跟着 CVM 走，内存规格优先，计费方式先按量后包年
• 账号：按用途分号，应用账号只要单库增删改查，清表权限留给人工
• 连接：内网为主，外网地址应急时开、用完就关
• 连接数：盯监控配告警，连接池大小别跟着网上抄来的数字走

下一篇是本篇的续集，也是全书最惊险的一节：误删整库之后，怎么靠备份和回档把数据救回来。建议现在就翻过去读一遍——别等出了事才第一次看。

延伸阅读

• 云数据库 MySQL 官方文档
• 1Panel 常见问题
• DeepSeek 工具链实战