补充一个实操视角：前面几位把排查顺序讲得很全了，我就补一个“现场 15 分钟止血清单”，重点是每一步先看什么、再动手，避免在连接满的时候越操作越堵。一、先保住管理通道，别用业务连接去重试新连接已经进不来时，不要让应用继续重试建连接，那只会把最后的名额也占满。先用已有连接、RDS 控制台的会话管理或 DAS 进去看现场。MySQL 给高权限账号预留的额外连接是救命通道，不要把它交给业务重试。二、先定性：是空闲占着，还是都在干活看三个数就够了：Threads_connected（当前连接数）、Threads_running（正在执行的连接数）、max_connections。- connected 接近上限、running 很小：连接都被占着但多数空闲，方向是连接泄漏、连接池过大或空闲回收没生效。- running 也很高：连接都在干活，方向是慢 SQL、锁等待或真实流量突发。这个区分决定了后面该杀连接、还是该限流、还是该优化 SQL，不要跳过它直接调参数。三、按来源分组，别只看总数用 processlist 按账号、来源主机、状态分组：哪台应用主机、哪个账号占了大头，往往就是泄漏或扩容失控的服务。特别注意“实例数 × 单实例连接池上限”这个总账：10 个实例、每池 50 个连接就是 500，早就超过了很多实例的默认上限，单看一个实例的池配置是看不出来的。四、止血只动“已确认、无业务影响”的连接确实要腾连接时，先把 processlist 完整导出留存，再逐个处理长时间 Sleep、来源明确为已下线服务或非核心任务的会话。不要批量 KILL 正在执行的业务连接，也不要直接重启实例：重启会清掉现场，泄漏问题几小时后还会复发。五、调大上限前先算两笔账1. 内存账：每个连接除了线程栈，还会按需分配排序、连接等缓冲区，连接数从几百调到几千，极端并发下内存可能成倍上涨，别把“连接满”调成 OOM。2. 规格账：上限要和实例规格绑定，升规格是买余量，不是根因修复。六、长期把“应用连接数”和“数据库连接数”解耦最彻底的是在应用和数据库之间加一层连接复用，例如 RDS 数据库代理，把上万个应用空闲连接收敛成后端几十条物理连接；只读流量分到只读实例，也能直接给主库减压。同时把连接数使用率告警设在 70%～80%，并要求连续多个周期触发，别等到应用报 Too many connections 才发现。一句话：先保通道、再定性、再分组、再止血、最后才动上限；每一步先确认影响面，再动手。

先说结论：只重装 TPOPS 软件本身，一般不需要重新激活许可，ESN 也不会变；但前提是同一台机器、同一套硬件，且许可文件没有被删掉。下面分三个问题说清楚。 ESN 会变吗？一般不会。ESN 是设备的出厂序列号，绑定的是硬件身份，不是某一次软件安装生成的随机号。只重装 TPOPS、重置控制台配置，不会改变服务器的 ESN。只有换主板、换整机、或者硬件信息被重置这类情况，才可能导致系统识别到的 ESN 变化。所以重装前先把当前 ESN 记下来，重装后第一时间核对一次，两次一致就基本可以排除 ESN 变化这个因素。 二、需要重新激活吗？ ESN 不变且许可文件还在，一般不需要。许可通常是按 ESN 绑定的，只要 ESN 对得上、许可文件完整，TPOPS 恢复后应能直接识别原许可。但要注意一个例外：重装过程中如果把许可文件、许可目录一并清掉了，即使 ESN 没变，系统也找不到原许可，这时就需要重新导入许可文件，而不是重新购买。所以重装前务必先备份许可文件和 TPOPS 配置，并确认备份能恢复。 ESN 真变了怎么办？原许可确实不能直接在新 ESN 上用，因为许可与旧 ESN 绑定。这时不要用非官方渠道的许可文件，正确做法是走官方支持渠道申请许可转移或临时许可：准备好旧 ESN、新 ESN、原许可信息和订单或合同信息，说明是同一套环境重装或硬件更换导致的 ESN 变化。临时许可通常有使用期限，只能作为过渡，正式许可下来后要及时替换，避免临时许可过期后服务中断。 另外提醒一TPOPS 异常先不要急着重装。先看 TPOPS 的服务状态和日志，确认是控制台本身异常，还是底层数据库、网络、磁盘空间的问题；重装前先对数据库和 TPOPS 配置做备份。重装能解决控制台损坏的问题，但解决不了底层资源或配置错误，备份做好了，重装后即使要重

补充一个已采纳回答之外、可以直接落地的思路：先把深分页的代价从回表降到只扫索引，再把任意跳页换成可缓存的页锚点。 一、先做覆盖索引，让延迟关联真正不回表你现在的查 order_no、user_id、amount，这些列不在 (created_at, id) 上。建议建一个只服务这个列表页的覆盖索引，把查询列都放进去：CREATE INDEX idx_order_list ON order_item (created_at, id, order_no, user_id, amount); 这样内层取 id 时可以只读索引，深分页往往能从 8 秒降到 1 秒量级。但注意它仍然要沿索引跳过 100 万条，只是每条代价变小了，所以它不是 100ms 的解法，只是兜底。 二、任意跳页不 offset 去数，用页锚点去定位MySQL 没有第 N 条的直接定位能力，offset 的语义就是逐条跳过，所以任意页 100ms 在纯 SQL 层面基本无解。可行的工程做法是：用户顺序翻页时，把每一页最后一条的 id 存下来，key 按筛选条件加页码存到 Redis，例如 list:order:筛选条件:page:5000 对应锚点 id，TTL 比如 10 分钟。用户点第 5000 页时，先查缓存有没有锚点，有就直接用 keyset 查询：WHERE created_at >= ? AND created_at ? AND id 锚点 id ORDER BY id DESC LIMIT 20，基本是毫秒级。缓存没有锚点时，不要直接跑 LIMIT 1000000,20，而是先跑一个只取 id 的边界查询拿到起始 id，再用 keyset 取整行；或者提示缩小时间范围或从附近页进入。管理后台的真实用户很少会凭空跳到第 5 万页，多数是误点或爬虫。 三、把时间范围变成第一道过滤器，而不是可选项你已经观察到时间范围越宽变慢越早。管理后台可以默认只 7 天，查更久必须显式选时间并走异步导出，而不是在线翻页。对历史数据查询，建议走导出 CSV 或异步任务加文件下载，不要让在线列表承担全量翻页。 四、总数不要和列表一起实时COUNT(*) 在大范围下同样要扫很多行。总数可以单独缓存，key 按筛选条件，TTL 5 分钟；或者只显示 10000+ 这种近似总数。把 SQL_CALC_FOUND_ROWS 拿掉是对的，它会让优化器多做一次计数。 推荐的落地组合是：覆盖索引 + keyset 顺序翻页 + 页锚点缓存支持跳页 + 默认窄时间范围 + 总数缓存。先上覆盖索引和 keyset，线上深分页的超时基本就能解决；跳页锚点是第二步，专门用来满足产品能跳页的要求，而不必为每一页都付出 offset 的全量扫描代价。兜底算查最近要用询要取

补充一个应急视角：磁盘已经到 90% 时，首要目标是先争取时间、再安全地断开已经放弃的复制槽，顺序错了很容易把主库也拖垮。 一、先确认到底是不是这个槽在拖 WAL只看磁盘使用率不够，建议同时查三处：复制槽的 active 状态和 restart_lsn 是否连续两天不动、pg_stat_replication 里是否还有对应的 walsender 在推进、以及 WAL 的增长速度。如果 restart_lsn 长时间不动、confirmed_flush_lsn 也不推进，基本可以锁定是该槽在保留 WAL；如果还有多个槽，也要逐个对比保留量，不要只凭名字猜。 二、先止血，不要先删文件千万不要手动删除 pg_wal 目录下的 WAL 文件，也不要为了腾空间随意重启主库。手动删 WAL 会破坏复制位点和时间点恢复能力，RDS 托管实例更不建议绕过控制台直接动底层文件。更稳妥的止血办法是：在 RDS 控制台先确认存储空间能否临时扩容，同时暂停非必要的写入任务和大事务，给处理留出窗口；如果磁盘还在快速上涨，扩容只是买时间，最终还是要处理复制槽。 三、确认下游确实不再消费，再动手在删槽之前，至少要确认两点：下游负责人明确表示该订阅已停用或已废弃；下游数据库里对应的订阅确实不再连接和推进。如果下游只是暂时断网、计划恢复，就不要删槽，删槽后下游无法从旧位点续传，只能重建订阅并重新做初始同步，代价远大于多保留一段时间的 WAL。 四、删槽后要验证 WAL 真正释放删除复制槽本身不会立刻让磁盘使用率下降，WAL 需要在检查点之后才会被回收复用。删槽后建议观察 restart_lsn 是否不再被旧槽拖住、磁盘使用率是否停止上涨并逐步回落；如果仍然满，要继续排查其他复制槽、未归档的 WAL、长时间未提交的事务和归档失败，而不是反复删槽。 五、事后防复发建议把复制槽纳入日常巡检：定期清理已废弃的槽，给磁盘使用率设置 70% 和 85% 两档告警；下游任务要有明确负责人和停用流程，停用订阅时同步删除对应的槽；同时在变更前记录槽名、restart_lsn 和 confirmed_flush_lsn，万一需要回溯也有据可查。 一句话总结：先定位到不动的槽、再向下游确认废弃、最后在低峰删槽并验证 WAL 回收，删槽影响的是该订阅的续传能力，不会改动已有表数据，但下游要重建订阅才能重新同步。

补充一个更贴近北向对接的查法：楼上讲的是口径，我这里说字段来源和校验方法。 一、先区分三列，不要用分配率代替平均使用率。分配率是已分配量除以总量，平均使用率是统计周期内实际使用量的均值除以总量。所以截图里出现分配率较高、平均使用率却很低的行是完全可能的，说明资源分配出去了，但虚拟机实际并没有用满。 二、继续用提问中步骤3的接口核对。调用 POST https://{运维侧对外访问域名}/rest/analysis/v1/datasets/stat-hypervisor?pageNo=1&pageSize=1000 时，请求条件里要带齐区域、资源池或可用分区、主机组标识，返回结果按主机组聚合后，先看除了总量、已分配量、剩余量之外，是否已经直接给出了平均使用率字段。如果返回的是逐主机明细，就不要把各主机的百分比直接算术平均，而要按容量加权汇总，公式是：主机组内存平均使用率等于各主机内存实际使用量均值之和，除以各主机内存总量之和，再乘以100%，CPU同理。主机规格不一致时，直接平均百分比会失真。 三、如果该接口确实只给总量和分配量、没有平均使用率，就到监控侧补数。按同一区域、同一主机组、同一时间范围，取各主机CPU和内存使用率曲线，先做时间平均，再按总量加权汇总到主机组。时间范围、聚合粒度、主机范围三者必须与容量报表一致，否则一定对不上。 四、用截图里的一行做校验。CPU总量6099、分配率28.40%那行，CPU平均使用率只有9.47%，说明CPU分配了但没用满；而同一行的内存总量8713.67、分配率63.04%，内存平均使用率61.07%，说明内存确实占用较高。扩容判断要以平均使用率为准，不能只看分配率。另外要排除统计期内上下线、迁移、关机或缺采样点的主机，否则总量变化或缺失点按0计算都会拉偏平均值。 建议北向拉数时一次取齐总量、已分配量、剩余量、分配率和平均使用率，并把起止时间、聚合粒度、主机组标识一起保存下来，后续对账才有口径可查。

补充一个容易被忽略的排查角度：先把密钥和密码两条路彻底分开测，再查账号状态，而不是把六个可能混在一起试。 一、先分开测，定位是哪条路坏了ssh -o PreferredAuthentications=publickey -i 本地私钥 用户名@公网IPssh -o PreferredAuthentications=password -o PubkeyAuthentication=no 用户名@公网IP如果只用密钥失败、只用密码能进，问题就在密钥侧；如果两条都失败，重点就不是某一把钥匙，而是账号本身或 sshd 的认证策略。注意看报错后缀：Permission denied (publickey) 说明服务端当时只接受密钥，密码试再多次也没用；出现 (publickey,password) 才说明密码这条路也被服务端放行了。 二、通过控制台远程登录查账号状态远程登录不走 sshd，进系统后先确认三件事：1. 这个用户是不是真的存在，家目录是不是你以为的那个：id 用户名，ls -ld ~，避免公钥写进了 root 的家目录、登录时却用了 ubuntu 这类错位。2. 账号有没有被锁、密码是不是空：sudo passwd -S 用户名，看到 LK 或 NP 就说明账号被锁定或根本没有可用密码，密钥对登录创建的实例出现后者很常见，这时密码被拒不是密码记错。3. 实例有没有被重建、从自定义镜像恢复过：这种情况下实例里的 authorized_keys 可能还是旧镜像里的内容，控制台显示的密钥对名称对了也不代表实例里就是这把公钥，仍要以实例内 authorized_keys 的实际内容和指纹为准。 三、确认你连的确实是 22 端口的 sshd如果之前改过 SSH 端口，或者装过安全加固基线，sshd 可能不在 22 上：远程登录里用 ss -tlnp | grep sshd 确认实际监听端口，再用 ssh -p 实际端口测试。端口不对时，客户端可能连到了别的服务，也会表现为认证失败，容易误判成密钥问题。 按这个顺序：先分开测定性，再进系统查账号和实际端口，最后才回到常规的权限、公钥、sshd 配置清单，往往能少走很多弯路。

这个问题很常见，建议先把【没有 SSH】拆成两种情况，对症处理： 一、本地没有 SSH 客户端最省事的是用云主机控制台自带的网页终端：华为云控制台 → ECS → 远程登录（VNC / CloudShell 方式），直接在网页里操作服务器，本地不需要装任何客户端。小文件可以通过网页终端的上传功能或复制粘贴传进去，应急完全够用。 二、服务器 22 端口被封、或公司网络不允许出站 SSH这种情况下有几种不走 SSH 的同步办法：1. 对象存储中转：本地把代码打包上传到 OBS，云主机上用 obsutil 定时拉取并解压。适合发布包、静态资源的同步，缺点是做不到实时。2. DevOps 流水线：把代码推到 CodeArts 代码托管，配置一条构建→部署到主机的流水线（主机组用 agent 接入，不依赖 SSH），push 代码后自动同步到服务器，团队协作里这是最规范的做法。3. VS Code Remote Tunnels：在云主机上运行 code tunnel，走的是 HTTPS 出站中继，本地 VS Code 通过隧道连接，全程不需要开放 22 端口，还能直接远程开发、调试、看日志，体验接近 SSH。4. 先排查最简单的原因：如果只是安全组没放行 22 端口，在控制台安全组里放通自己出口 IP 的 22 端口即可，比绕路省事得多。 选型建议：临时传个文件，用网页终端或对象存储最快；长期开发维护，推荐流水线自动部署或 Remote Tunnels。先确认自己属于哪种没有 SSH，能少走很多弯路。