结论：本地能登录只证明 root 本机通道通了，不能证明业务通道通了。按“报错、业务账号、业务配置、监听与安全组”顺序查，先定性再改配置。一、先看业务报错：1045 是账号、密码或主机授权问题；2003 或超时是监听、端口或安全组问题；1049 是库名问题，分支不同路径不同。二、确认业务用哪个账号：重置的常常只是 root，业务若用另一账号，改 root 对它无效。查 SELECT user,host FROM mysql.user；核对主机、是否锁定、密码是否过期、认证插件是否一致。三、同步业务配置并重启：把新密码同步到业务配置或密钥中，改完重启业务或重建连接池，否则旧密码仍在缓存连接里。四、在业务机上复现：用业务账号执行 mysql -h 内网 IP -P 3306 -u 业务账号 -p；能连上是业务侧问题，连不上再查 bind-address、安全组与防火墙 3306。

补充一个可直接落地的选型方法，核心是先测瓶颈、再定配比、最后用监控调档，而不是先定一个大规格长期持有。第一步：先看瓶颈，不要先看价格。登录服务器执行：uptime；free -h；vmstat 1 5；iostat -x 1 5；df -h。重点看四个数：CPU峰值利用率、内存剩余和是否用到Swap、磁盘await和IOPS、网络收发包是否打满。哪个先到瓶颈，就按哪个定实例族：CPU先满选计算型，内存先满选内存优化型，磁盘IOPS先满选磁盘增强型或超高I/O型，均衡负载选通用型。第二步：按峰值定档，留20%到30%余量即可。举例：Web应用峰值2核跑到70%、内存用到5GB，就不要直接买8核32GB，先从4核8GB这类通用规格起步；Redis、缓存类内存占用高、CPU相对低，就优先保证内存配比，例如4核16GB比8核8GB更合适。测试环境和生产环境分开定，测试用入门或通用规格就够了。第三步：计费和带宽分开算。短期验证、波动大的业务先用按需计费跑稳，确认负载稳定后再评估包年包月；流量波动大的业务不要把公网带宽一次买满，先满足当前峰值，后续按监控扩容。峰值有明显波峰波谷的业务，优先考虑弹性伸缩加负载均衡，用多台中等规格分担峰值，比单台超大规格更稳、也更容易降成本。第四步：上线后一周复核一次。去云监控看CPU、内存、磁盘、网络曲线：峰值长期低于30%就降一档；峰值经常超过80%、或出现Swap、磁盘await持续偏高就升一档或换实例族；每次只调一档，调完再观察一周。变更规格前先做数据备份，按控制台变更规格流程操作，变更后重新跑一遍业务高峰验证。一句话总结：瓶颈决定实例族，峰值加两三成余量决定档位，监控决定升降档，计费方式决定长期成本。这样既不会为闲置算力长期付费，也不会在高峰时因为规格不够而卡顿。

可以把拥塞窗口随时间的变化当成主线。慢启动：窗口从 1 个 MSS 起，每收到一个 ACK 翻倍，直到慢启动阈值；拥塞避免：每轮只加 1 个 MSS，线性增长；丢包时触发快速重传：收到 3 个重复 ACK 立即重发，不等超时；快速恢复：把阈值减半后不回到慢启动，而是用减半后的窗口继续线性增长。CUBIC 与 BBR 的思路差异：CUBIC 以丢包为拥塞信号，用三次函数调整窗口；BBR 不依赖丢包，主动探测带宽与最小 RTT，把发送速率控制在带宽时延积附近，丢包时不盲目降速。Linux 上可验证：sysctl net.ipv4.tcp_congestion_control 查看当前算法，临时切换用 sysctl -w；再用 iperf3 打流对比两种算法的吞吐与重传率；用 tc netem 注入丢包或时延，看窗口变化。云上注意：EIP 限速造成的丢包容易被误判为拥塞，先确认是否触发限速再调算法。

先量化再定策略。定位：用 ListMultipartUploads 按前缀分段拉取未完成上传，统计 uploadId 数量、已传分片大小和最早发起时间，先确认是哪类业务、前缀占比最高，再定过期天数，不要一上来就全桶一刀切。规则上：生命周期规则支持清理未完成分段上传，建议按前缀分层设过期，例如临时目录 3 天、正式目录 7 天，兼顾断点续传窗口和成本。工程侧：上传开始时把 uploadId、key、过期时间落库；完成时清库；取消或失败时在 finally 里 abort；再用每天一次的兜底任务只扫库里超期的 uploadId 逐个 abort，避免全桶扫描。监控上：对未完成上传数量、占用空间设告警，突增时先查客户端超时配置和网络重试逻辑。历史遗留的一次性清理可用 obsutil 列出并批量 abort，执行前先按前缀导出清单核对。

先分清两种情况：EXPLAIN 的 type、rows 没变，还是计划变了但耗时没变，排查方向完全不同。建议按这个顺序做：一是看慢日志里该 SQL 的平均耗时、扫描行数与返回行数，确认瓶颈在扫描还是回表；二是用 SHOW INDEX 看 user_id 的区分度，单个用户订单很多时单列索引过滤有限；三是跑 ANALYZE TABLE 更新统计信息，再用 EXPLAIN 对比估算行数与实际行数；四是临时用 FORCE INDEX 强制走该索引，若明显变快，说明优化器选错，可补直方图。类型问题先排除：user_id 是 bigint，入参传字符串会隐式转换导致索引失效。回表方面，除覆盖索引外，可把 ORDER BY create_time DESC 改为按 id 倒序游标分页，避免大偏移量 filesort；并精简 SELECT 列，减少回表宽度。

前面几位已经把按瓶颈定族、计费方式拆分讲得很全了，我补充一个前面没系统讲的角度：别只在规格上省，用架构把固定成本变可变成本。 一、把不该 ECS 扛的流量挪出去静态资源（JS、CSS、图片、视频）走 CDN+OBS，ECS 只留动态计算；图片视频不要长期存在云盘上，转对象存储。很多“ECS 不够用”其实是静态流量把带宽和连接数吃满了，挪出去之后，原规格往往就够了。 二、无状态、可中断的任务别用常驻 ECS离线批处理、定时任务这类无状态、可重试的活，用函数计算或容器混部替代 7×24 常驻的 ECS：有请求时才计费、闲时不花钱，等于把固定成本变可变成本。常驻 ECS 只留给必须 7×24 在线的核心服务。 三、升配前先做三项免费检查，加核数解决不了这三类问题1）慢 SQL / 缺索引：先查慢日志，全表扫描的 SQL 加核也快不了；2）连接池打满：连接池太小会让请求排队，看起来像 CPU 不够；3）缓存命中率：缓存没命中，请求全打到数据库和 ECS 上，升配只是把瓶颈往后推。这三项查完再谈升配，避免花了钱还没效果。 四、算总成本，别只看“几核几 G”ECS＋云盘＋公网带宽/流量＋快照备份＋日志监控要一起算：带宽和云盘经常是被漏掉的大头，单比核数内存会算错账。 五、一个可落地的决策流程按需开小规格跑一周，看 CES 的四项：P95 CPU、内存、云盘 IOPS、出网带宽；基线负载转包年包月锁单价，周期性峰值交给伸缩组按需付费；上线后连续 14 天 P95 CPU 低于 20% 且内存低于 30% 就降一档。先小后大、按监控升降，比一次买满便宜得多。

多半是登录时要拉起浏览器做授权、没拉起来造成的，可以依次排查：1、先在 IDEA 设置 → 插件里把 CodeArts 插件更新到最新版。IDEA 2026.1.5 版本比较新，旧版插件有兼容问题，点登录就会没反应。2、点登录后切出去看一下默认浏览器有没有打开华为账号授权页；没弹出来的话，换个默认浏览器再试一次。3、如果开着代理/VPN，先关掉或把华为云相关域名放行，授权回调被拦截时插件端就一直无响应。4、还不行的话，清一次 IDE 缓存重启（Invalidate Caches），再看 idea.log 里有没有插件报错。一般先升级插件 + 确认浏览器授权页能弹出来，多数情况就解决了。

我的经验是先画像、再选型，别一上来就盯着 CPU 核数。第一，先明确业务画像：你的负载是 CPU 密集、内存密集还是 IO 密集？流量是平稳的还是有明显波峰？这三个问题答完，规格的大方向就定了七成——比如静态站点和小流量服务，瓶颈往往在带宽和磁盘 IO，不在 CPU。第二，从小规格起步，用数据说话。新业务先上低一档的规格，跑一周看监控（CPU、内存、磁盘 IO 的峰值和均值），利用率长期低于三成就是买大了，峰值打满再升档。云服务器升档容易，降档往往要停机，先小后大更稳。第三，计费模式比规格更影响总价：长期稳定的业务用包年包月，单价明显低；短期、弹性大的用按需；能中断的批处理任务可以看竞价实例。同规格换个计费方式，省下的钱经常比降一档配置还多。第四，别忽略隐藏成本：带宽的计费方式（按流量还是按带宽）、云盘类型、公网 IP 费用，这些加起来可能超过主机本身。我的一个实际体会是：与其加 CPU，不如把钱花在 SSD 云盘和带宽上，用户体感提升更明显。第五，定期复盘。业务会变，三个月回头看一次利用率，低峰期该降配就降配。高配闲置是最常见的浪费，没有之一。