研发平台更换国产数据库后变慢，通常要从适配差异入手定位：先确认哪些功能、哪些时段变慢，再按数据库层、连接与驱动层、SQL与数据层、配置环境层、应用层逐项验证原因，最后按风险从低到高处置并复测。本文给出一套可执行的排查顺序、证据判定方法和恢复验证口径，适合研发平台负责人、运维和DBA在信创适配阶段使用。排查任务、变更评审和验证结论可以在ONES中流转和留痕。
要点总览（TL;DR）
- 先界定症状与范围：按页面加载、列表查询、保存提交、批量任务、报表导出分别记录更换前后耗时，统一数据量与并发口径，再判断异常先出现在应用层、网络层还是数据库层。
- 按层验证原因：依次核对数据库层的慢查询与执行计划、锁等待，连接与驱动层的连接池和驱动版本，SQL与数据层的分页排序与字符集排序规则，配置环境层的参数与规格，以及应用层的缓存与事务边界，每条假设都要有证据支撑。
- 处置按风险排序：先采集基线，再做更新统计信息、补缺失索引、调连接池等低风险调整，索引重建、SQL改写、参数调整和数据归档放到评审后的变更窗口执行。
- 涉及生产数据的操作先备份并写明回滚方式，出现错误率上升、慢查询反弹或锁等待加剧立即停止并回退。
- 恢复验证用同一批典型请求复测响应时间、错误率、慢查询数量和锁等待时长，达到约定标准后把慢查询基线和执行计划回归纳入日常监控与上线检查。
变慢出现在哪些环节：先界定症状与影响范围
“平台变慢”是笼统感受，排查第一步是把它拆成可观测的指标。建议按功能路径分别记录耗时：页面首次加载、列表与搜索查询、表单保存提交、批量导入导出、定时任务、报表统计。每类操作记录更换前的基线值、更换后的实测值、数据量和并发条件，形成可对比的口径。
影响范围决定排查起点。需要确认变慢是全平台普遍现象，还是集中在特定模块、特定项目空间、特定角色或特定时段。如果只有报表类功能变慢，优先怀疑聚合查询和排序；如果所有页面都慢，优先检查连接建立、网络时延和数据库整体负载；如果集中在工作时间高峰，优先看锁等待和资源争用。
对比口径要统一：同一操作、同一数据量、同一并发数、同一网络位置。更换前没有留下基线的，可以用当前数据量在测试环境回放典型请求，或选取业务低峰时段的稳定值作为参照，并在记录中注明参照来源，避免把不同口径的数字直接相减。
完成上述记录后，先做一次初步分层判断：应用服务器自身的CPU、内存、线程池是否饱和；应用与数据库之间的网络往返时延是否明显上升；数据库侧CPU、IO、活跃会话数是否异常。三者中哪一项先出现异常，就把排查重心放到对应层，其余层保留观察。
| 记录项 | 填写内容 | 用途 |
|---|---|---|
| 受影响功能 | 页面加载、列表查询、保存提交、批量任务、报表导出 | 区分单点问题与普遍问题 |
| 耗时对比 | 更换前基线、更换后实测、数据量、并发数 | 判断劣化幅度 |
| 影响范围 | 全平台/特定模块/特定项目/特定时段 | 缩小排查范围 |
| 初步分层判断 | 应用层、网络层、数据库层哪项先异常 | 确定排查起点 |
可能原因与排除证据：按层列出假设并逐一验证
国产数据库在SQL解析、执行计划生成、默认参数、字符集与排序规则、驱动协议上与原库存在差异，变慢往往来自多处小差异叠加。下面按层列出常见假设，每条都给出验证手段和判定标准。排查时先验证影响面最大、取证成本最低的假设，确认一条再进入下一条，避免同时改动多个变量。
数据库层
打开慢查询日志，按执行时间排序取前若干条样本，与更换前的慢查询记录对比。对同一条SQL分别查看新旧执行计划，重点看访问路径是否从索引扫描变为全表扫描、连接顺序是否改变、是否出现临时表和文件排序。执行计划劣化的常见原因是统计信息未收集或采样不足、索引在新排序规则下未被使用、优化器参数与原库默认值不同。判定标准是：能在执行计划中找到具体算子差异，并用强制索引或补充统计信息后复测确认耗时下降。
锁与等待事件需要单独看。查询数据库的等待事件视图，确认时间消耗在锁等待、IO等待还是CPU计算。如果大量会话处于行锁或表锁等待，结合业务时段定位是哪个批量任务或长事务持有锁。判定标准是等待事件占比和持锁会话可被明确指认。
连接与驱动层
连接池参数需要与新库的连接成本匹配。检查最大连接数、最小空闲连接、获取连接超时、空闲检测语句是否适配新库。驱动版本过旧可能导致协议兼容问题或额外往返。验证手段是观察连接获取等待时间、连接建立次数和超时重试日志；判定标准是连接获取耗时稳定且在超时阈值以内，重试次数归零。
SQL与数据层
分页与排序写法在新库上可能生成不同的执行计划，尤其是大偏移量分页和多重排序。字符集与排序规则差异会影响索引使用和比较结果，需要核对字段排序规则是否与查询条件一致。批量写入方式也要验证：逐条提交、批量提交、事务大小不同，写入耗时差异明显。验证手段是对比单条SQL在新旧库的执行计划和实际耗时，判定标准是同一SQL在新库上的耗时接近基线或差异可被算子解释。
配置与环境层
核对数据库关键参数：内存分配、并发连接上限、日志写入策略、并行度设置。资源规格方面确认新库部署的CPU、内存、磁盘IO是否与原环境相当。网络时延用应用服务器到数据库的往返时间衡量。读写分离或缓存策略若在更换中调整过，需要确认读请求是否仍命中预期节点。判定标准是参数与规格差异能被量化，并与变慢时段对应。
应用层
缓存命中率下降会让原本被缓存挡住的查询直接打到数据库；序列化方式变化会增加单次请求开销；事务边界过大导致持锁时间变长；重试与超时设置不当会在慢请求上叠加放大。验证手段是查看应用监控中的缓存命中率、单请求耗时分布和重试计数，判定标准是应用侧指标变化能解释部分耗时增量。
| 层次 | 原因假设 | 验证证据 | 判定标准 |
|---|---|---|---|
| 数据库层 | 执行计划劣化、统计信息过期、索引未生效 | 慢查询日志、新旧执行计划对比 | 算子差异可指认，调整后耗时下降 |
| 数据库层 | 锁等待、长事务 | 等待事件视图、持锁会话 | 等待占比高且持锁来源明确 |
| 连接与驱动层 | 连接池参数不匹配、驱动版本旧 | 连接获取耗时、重试日志 | 连接获取稳定、重试归零 |
| SQL与数据层 | 分页排序写法、字符集排序规则差异 | 单条SQL新旧库耗时对比 | 差异可被执行计划解释 |
| 配置与环境层 | 参数、规格、网络时延、读写分离 | 参数清单、资源监控、往返时延 | 差异量化并与变慢时段对应 |
| 应用层 | 缓存命中下降、事务边界过大、重试放大 | 应用监控、耗时分布、重试计数 | 应用指标变化解释部分增量 |
按顺序处置：从低风险动作到需要变更窗口的操作
处置遵循“先取证、后改动，先低风险、后高风险”的顺序。每一步开始前记录当前状态，结束后立即用同一批请求复测，确认有效再进入下一步。同时只改一项，避免多个变量叠加后无法判断哪项起了作用。
第一步：采集基线。保存慢查询样本及对应执行计划、关键接口的响应时间分布、数据库等待事件快照、连接池运行指标。基线是后续所有对比的参照，也是回滚后判断是否恢复原状的依据。这一步只读不写，风险最低。
第二步：低风险调整。包括更新统计信息、修正明显缺失的索引、调整连接池大小与超时参数、修正应用侧重试次数。这些操作影响面可控，多数可在业务运行中完成。每项调整后观察一个完整业务周期，确认慢查询数量和执行时间同步下降。
第三步：需要评审或变更窗口的操作。包括索引重建、SQL改写、数据库参数调整、历史数据归档。这类操作可能影响写入性能、占用大量IO或改变执行计划，须提前评审，选择低峰期执行，并准备回滚脚本。索引重建前确认磁盘空间充足；SQL改写前保留原语句以便对比；参数调整前记录原值。
涉及生产数据的操作，执行前必须完成备份，并明确停止点：出现错误率上升、慢查询数量反弹、锁等待加剧中任一情况，立即停止当前操作并回退到上一步的基线状态。回滚方式在操作前写清楚，包括恢复备份、还原参数、回退SQL版本的具体命令或流程。
| 步骤 | 典型动作 | 前置条件 | 风险与回滚 | 停止点 |
|---|---|---|---|---|
| 采集基线 | 保存慢查询、执行计划、接口耗时、等待事件 | 只读权限 | 无写入风险 | 样本覆盖典型功能即可 |
| 低风险调整 | 更新统计信息、补缺失索引、调连接池与超时 | 变更记录、观察窗口 | 影响面小，参数可还原 | 复测无改善则回退该项 |
| 变更窗口操作 | 索引重建、SQL改写、参数调整、数据归档 | 评审通过、备份完成、低峰期 | 影响写入与IO，需回滚脚本 | 错误率上升或锁等待加剧立即停止 |
排查过程本身也需要管理：谁负责取证、谁执行变更、谁做复测、评审结论记录在哪里。这类任务和变更记录可以在ONES中建立工作项，把慢查询样本、执行计划、变更单和复测结果关联到同一事项下，评审通过后再进入执行，避免口头确认导致回滚依据缺失。
恢复验证与复发预防：确认恢复并把基线固化下来
处置完成后，用与排查初期同一批典型请求、同一数据量复测，对比更换前基线和处置后耗时。验证维度至少包括：关键接口响应时间、请求错误率、慢查询数量、锁等待时长、批量任务完成时间。单项指标恢复不足以判定结束，需要多项同时回到可接受范围，且稳定观察一个完整业务周期。
恢复判定标准建议事先约定，例如关键接口P95耗时回到基线的一定比例以内、慢查询数量降到更换前水平、无新增锁等待告警、批量任务在既定窗口内完成。达到标准后可结束本次排查，未达标的指标列入持续观察清单，注明责任人和复查时间。
复发预防的关键是把这次排查得到的基线固化下来。将典型SQL的慢查询阈值、执行计划快照、容量与并发阈值纳入日常监控；在上线检查中加入数据库适配项，包括统计信息是否更新、新增SQL是否走过执行计划评审、连接池参数是否随并发调整。后续数据库版本升级、参数变更或数据量跨过新量级时，重复同一套适配验证，用相同口径复测，避免同类问题在下次变更中重新出现。
- 监控项：慢查询数量与耗时分布、执行计划变化告警、锁等待时长、连接池获取耗时、批量任务完成时间。
- 上线检查项：统计信息更新、新增SQL执行计划评审、连接池与超时参数核对、字符集与排序规则一致性检查。
- 变更触发条件：数据库版本升级、关键参数调整、数据量增长跨量级、读写分离或缓存策略调整。
常见问题
更换国产数据库后只有报表导出变慢，其他功能正常，应该先查哪里？
影响范围集中在报表类功能，排查重心放在聚合查询、排序和大结果集处理上。先取报表相关SQL的慢查询样本，对比新旧执行计划，重点看是否出现全表扫描、临时表或文件排序；再核对报表涉及的字段排序规则与查询条件是否一致，以及统计信息是否已在新库收集。若报表走的是只读节点或缓存，还需确认更换后读请求是否仍命中预期节点。
没有保留更换前的性能基线，还能判断是否恢复吗？
可以建立替代参照，但要在记录中注明来源。常见做法是用当前数据量在测试环境回放典型请求，或选取业务低峰时段的稳定值作为参照，也可以参考更换前监控系统里留存的历史曲线。替代基线的口径必须与复测一致，即同一操作、同一数据量、同一并发、同一网络位置。判定恢复时以多项指标同时回到可接受范围为准，单项达标不足以结束排查。
更新统计信息和补索引这类操作，需要停机吗？
多数情况下影响面可控，可在业务运行中完成，但要看具体数据量和数据库的锁行为。执行前记录当前状态和参数原值，选择低峰期操作，执行后观察一个完整业务周期，确认慢查询数量和执行时间同步下降。如果操作期间出现锁等待加剧或错误率上升，停止当前操作并回退到上一步的基线状态。索引重建这类占用大量IO的操作，建议放到评审后的变更窗口执行。
排查和变更涉及多个角色，怎么保证回滚依据不丢失？
把取证、变更执行、复测和评审结论落到同一处记录中，是避免口头确认导致依据缺失的常用做法。可以为每次排查建立独立工作项，把慢查询样本、执行计划、变更单、回滚脚本和复测结果关联在同一事项下，评审通过后再进入执行。这样回退时能直接找到原参数值、原SQL版本和备份位置。ONES可用于承载这类排查任务与变更评审的流转和留痕。
处置后指标恢复了，后续还要做哪些适配验证？
把这次排查得到的基线固化下来：典型SQL的慢查询阈值、执行计划快照、容量与并发阈值纳入日常监控；上线检查中加入统计信息更新、新增SQL执行计划评审、连接池与超时参数核对、字符集与排序规则一致性检查。后续数据库版本升级、关键参数调整、数据量跨量级增长或读写分离策略变化时，用相同口径重复同一套适配验证，避免同类问题在下一次变更中重新出现。
