国产数据库适配完成后，研发平台“能打开、能提交”只是第一步，真正需要回答的是：在日常研发使用中，性能是否仍然可接受。评估时应先确定目标和判定框架，再选定指标与业务场景，为每个指标写明取数口径，然后用同一批业务动作做基线对比和压力梯度测试，最后结合证据解释结果。ONES 信创版适配信创主流基础软硬件，覆盖芯片、操作系统、数据库等核心模块，其适配的数据库中列明达梦数据库；具体性能表现仍需在客户环境中按本文方法建立基线验证。
要点总览（TL;DR）
- 评估国产数据库适配后的研发平台性能，先明确目的：验收型判断是否达标，诊断型定位瓶颈在哪，两类评估共用指标但判定方式不同。
- 指标至少覆盖响应时间（P50/P95/P99）、吞吐量、错误率、数据库连接与慢查询、资源占用和长时间稳定性，场景覆盖列表筛选、详情读写、批量导入导出、报表统计、权限搜索和并发协作。
- 每个指标写明公式、分子分母、时间窗和单位，取数来源包括应用日志、APM、慢查询日志、系统监控和压测报告，超时请求计入失败并保留在分母中。
- 评估按建立基线、固定变量、并发梯度加压、计算变化率、分层定位异常点五步执行，变化率=（适配后−基线）/基线×100%，并附样本量与波动区间。
- 结论要绑定场景、数据量和硬件条件，多指标交叉判断，达标阈值来自业务要求或历史基线；适配认证与兼容版本以厂商正式材料为准。
评估要回答什么问题：适配后性能是否可接受
评估的起点是把“性能好不好”转成一组可回答的问题：在给定数据量、并发数和硬件环境下，研发人员完成列表筛选、详情读写、批量导入、报表统计等动作需要多长时间；高峰期系统能否稳定支撑；错误和超时是否在可接受范围内；如果出现退化，瓶颈在数据库层、应用层还是网络层。只有问题足够具体，后续的指标和取数才有落点。
按目的不同，评估可分为两类。验收型评估回答“是否达标”，结论是明确的通过或不通过，适合适配上线前的准入判断；诊断型评估回答“瓶颈在哪”，结论是定位到具体环节的改进线索，适合上线后性能波动或压测异常时使用。两类评估可以共用指标，但判定方式不同：验收型需要事先约定阈值，诊断型更关注指标之间的差异和变化方向。
评估结论必须绑定条件。同一平台在不同数据量、不同并发、不同硬件配置下的表现可能差异明显，脱离场景和数据规模给出的“性能提升多少”没有比较意义。因此每份评估报告都应写明测试场景、数据规模、硬件与网络环境、并发设置和测试时间窗，让结论可以被复算和复核。
指标与范围：选哪些指标、覆盖哪些场景
指标选择应覆盖用户体验、系统承载和资源消耗三个层面，避免只看单一接口耗时。下表给出建议的核心指标集合，实际评估时可按平台规模和业务重点取舍，但取舍理由应写入报告。
| 指标 | 说明 | 建议采集粒度 |
|---|---|---|
| 请求响应时间 | 分别统计 P50、P95、P99，反映典型用户与长尾用户的等待体验 | 按接口或业务动作分组 |
| 吞吐量 | TPS 或 QPS，表示单位时间内成功处理的请求数 | 按并发档位记录 |
| 错误率 | 失败请求数占全部请求数的比例，含超时和数据库报错 | 按场景和并发档位记录 |
| 数据库连接与慢查询 | 连接池使用率、等待连接数、慢查询条数及耗时分布 | 按时间窗统计 |
| 资源占用 | 应用与数据库的 CPU、内存、磁盘 IO 使用率 | 按分钟采样 |
| 长时间运行稳定性 | 持续运行数小时至数天内的指标波动、内存增长和错误累积 | 整段运行周期 |
场景范围应覆盖研发人员高频使用的业务动作：工作项列表与多条件筛选、需求与缺陷详情读写、批量导入导出、报表与度量统计、权限校验与全局搜索、多人并发协作操作。这些场景对数据库的压力类型不同，列表和报表偏重查询，导入导出偏重写入与事务，协作操作偏重并发连接，分开测试才能解释整体表现。
同时要明确纳入与排除范围。尚未上线的功能模块、极低频的管理操作、与本次适配无关的第三方集成，可以排除在评估之外，但应在报告中列明，避免读者把未测范围理解为已验证范围。
数据口径与证据：每个指标怎么取数
口径决定结果能否复算。每个指标都应写明计算公式、分子分母、统计时间窗和单位。例如 P95 响应时间指将时间窗内所有成功请求的响应时间升序排列后处于 95% 位置的值，单位毫秒；错误率等于失败请求数除以总请求数再乘以 100%，其中总请求数是否包含超时请求必须事先约定并保持一致；吞吐量等于时间窗内成功处理的请求数除以时间窗秒数，单位为 TPS 或 QPS。
取数来源要与指标匹配。应用日志和 APM、链路追踪适合获取接口级响应时间与错误分布；数据库慢查询日志和连接监控适合定位数据库层耗时；系统监控提供 CPU、内存、IO 曲线；压测工具报告提供并发档位下的吞吐与延迟汇总。多来源数据应能相互印证，出现明显矛盾时先核对时间窗和统计对象是否一致。
缺失值与异常值需要规则化处理。超时请求通常计入失败并保留在分母中，避免通过剔除慢请求美化结果；因测试脚本错误产生的无效请求应整条剔除并记录剔除数量；样本量过少的指标应标注“样本不足”，不参与结论性判断。测试数据规模也要说明与生产数据的比例，例如按生产工单量的十分之一构造数据，并注明字段分布是否做了脱敏和简化。
计算与评估步骤：从基线到压力梯度
第一步建立基线。优先使用适配前同一平台的同场景数据；如果适配前环境已不可用，可选择配置相近的参照环境，但需说明差异。基线数据同样要按上述口径采集，否则前后不可比。
第二步固定变量。硬件配置、数据量、并发数、客户端网络条件、测试脚本和思考时间都应保持一致，只把数据库环境作为变化因素。任何无法固定的变量都要在报告中披露。
第三步按并发梯度加压。例如从 20、50、100、200 并发逐档运行，每档持续足够时间以覆盖缓存预热和稳定期，记录每档的响应时间分位值、吞吐量、错误率和资源占用。梯度设计应覆盖日常负载和预期峰值，不必追求极限压测。
第四步计算对比。变化率公式为：变化率 =（适配后数值 − 基线数值）/ 基线数值 × 100%。结果为正表示上升，为负表示下降；对响应时间和错误率，上升通常意味着退化，对吞吐量则相反。每项变化率都应附样本量和波动区间，例如“P95 响应时间上升 18%，样本 12,000 次请求，三次重复测试波动范围 ±4%”。
第五步定位异常点。对明显退化的指标分层排查：数据库层看慢查询数量、执行计划和连接等待；应用层看接口内部耗时分布、线程池和缓存命中；网络层看往返时延和丢包。分层定位能把“适配引起的变化”与数据量增长、客户端环境等其他因素区分开。
在评估流程中，测试场景、指标口径和每轮结果需要被稳定记录和汇总。ONES 可承载工作项与度量统计的管理动作，团队可以把评估任务、测试轮次和结果数据作为工作项管理，便于按场景和版本追溯对比记录。
算例：一次列表查询的适配前后对比
以下为演示情景，数字仅用于说明计算过程，不代表任何产品的实际性能。设定场景为工作项列表按状态和负责人筛选，测试数据为 50 万条工作项，并发 50，每轮持续 10 分钟，适配前后硬件与数据量一致。
基线环境记录：成功请求 60,000 次，失败 300 次，P95 响应时间 420 毫秒，吞吐量 100 TPS。适配后环境记录：成功请求 57,000 次，失败 900 次，P95 响应时间 510 毫秒，吞吐量 95 TPS。总请求数分别为 60,300 和 57,900。
- P95 响应时间变化率 =（510 − 420）/ 420 × 100% ≈ +21.4%，表示长尾等待变长。
- 吞吐量变化率 =（95 − 100）/ 100 × 100% = −5.0%，表示单位时间处理能力略降。
- 错误率：基线为 300 / 60,300 × 100% ≈ 0.50%；适配后为 900 / 57,900 × 100% ≈ 1.55%，上升约 1.05 个百分点。
如果某一档并发下没有失败请求，错误率分母不为零但分子为零，结果记为 0%，并注明样本量；如果某场景因脚本故障没有产生有效请求，分母为零，此时不计算比率，标记为“无有效样本”，不得写成 0%。
结论表述应绑定条件，例如：“在 50 万条数据、50 并发、相同硬件条件下，适配后列表筛选场景 P95 响应时间上升约 21%，错误率由 0.50% 升至 1.55%，吞吐量下降约 5%；三次重复测试波动在 ±4% 以内，该退化幅度在本次测试条件下可复现。”这样的表述说明了变化幅度、方向和可信程度，也保留了外推边界。
解读与限制：结论能说到什么程度
单指标变化不能代表整体性能。响应时间上升可能伴随吞吐量基本持平，说明瓶颈集中在个别慢查询；错误率上升而响应时间正常，可能指向连接池耗尽或超时配置。解读时应把响应时间、吞吐量、错误率和资源占用交叉对照，再结合分层定位给出判断。
测试环境与生产环境存在差异。数据分布、历史数据积累、真实并发模式和网络链路都可能在测试中被简化，因此测试结论适合作为准入判断和优化线索，外推到生产时需要保留条件说明，必要时在生产灰度阶段补充观测。
达标阈值应来自业务要求或历史基线，例如研发人员可接受的操作等待时间、业务高峰的并发规模，而不是套用通用数值。没有基线时，先建立基线再谈变化幅度。适配认证与兼容版本属于另一类证据，应以厂商正式材料为准；ONES 信创版已与主流信创软硬件完成互信认证，其适配的数据库中列明达梦数据库，具体认证清单、版本范围和性能数据需以厂商正式材料及客户环境实测为准，评估结果本身不替代认证结论。
常见问题
适配前的环境已经下线，还能做基线对比吗？
可以，但需要换一种可比方式。优先选择配置相近的参照环境，用同一套测试脚本、相同数据量和并发设置采集数据，并在报告中说明参照环境与原环境的硬件、数据库版本差异。另一种做法是先在当前适配后环境建立基线，后续版本升级或参数调整时以它为参照，此时评估的是变化方向而非与原环境的绝对差异。无论哪种方式，基线数据都要按统一口径采集，否则前后不可比。
压测结果和真实生产表现差距较大，评估结论还能用吗？
压测结论适合作为准入判断和优化线索，外推到生产时要保留条件说明。差距常见来源包括数据分布被简化、历史数据积累不足、真实并发模式与脚本不同、网络链路更复杂。建议在报告中写明测试数据与生产数据的比例、并发模型的设计依据，并在生产灰度阶段补充观测，用真实指标验证压测结论。如果灰度阶段指标明显偏离压测结果，应回到分层定位，检查数据库层、应用层和网络层的差异。
错误率的分母要不要包含超时请求？
建议包含，并在所有轮次中保持一致。超时请求代表用户没有在预期时间内得到结果，属于失败体验，剔除它会美化错误率。如果团队希望单独观察超时情况，可以在总错误率之外再拆分一个超时率指标，但不要改变总错误率的口径。分母为零的场景（例如脚本故障导致没有有效请求）不计算比率，标记为“无有效样本”，不能写成 0%。
评估中发现的性能退化，怎么判断是不是数据库适配引起的？
靠分层定位和变量控制。测试时固定硬件、数据量、并发数、客户端网络和测试脚本，只把数据库环境作为变化因素，这样变化率才能归因到适配。出现退化后分层排查：数据库层看慢查询数量、执行计划和连接等待；应用层看接口内部耗时分布、线程池和缓存命中；网络层看往返时延和丢包。如果退化集中在数据库层且执行计划发生变化，适配因素的可能性较高；如果应用层耗时占比同步上升，则要排查连接池配置或驱动参数。
ONES 信创版在国产数据库上的性能数据可以直接引用吗？
官网信创页面说明了适配范围和互信认证情况，例如 ONES 信创版适配信创主流基础软硬件，覆盖芯片、操作系统、数据库等核心模块，适配的数据库中列明达梦数据库，并已与主流信创软硬件完成互信认证。页面未提供国产数据库环境下的性能测试数据，因此性能结论仍需在客户环境中按本文方法建立基线验证。具体认证清单、版本范围和性能数据以厂商正式材料为准，评估结果本身不替代认证结论。
