你知道有个非常简单的方法可以检查你的核心D365数据库是否正常吗？使用“运行性能测试”这个工具。
没必要启用所有测试。只要专注于那个1000条记录的插入页。
显示的是插入1000条记录所需的毫秒数。（你可以选择更高或更低的点来获得更好的平均分。）记得多跑几遍，感受一下平均值。
如果你在1000条记录上的PROD表现是
低于2000ms——你很不错，Azure SQL性能也很棒。我更喜欢看到1000毫秒，但这取决于你系统的负载
2000ms-3000ms——性能还可以，但你应该检查一下AOS没有崩溃导致SQL故障切换的情况。这也是二级环境的典型性能。
超过3000毫秒——如果持续高于3000毫秒，那很可能是问题，你应该提交支持请求进行遥测检查。
你也可以在trace解析器中看到性能测试，下面是在正常执行的PROD环境中进行10,000次插入时的样子。独家平均和0.78毫秒/插入时间相当不错。
执行的代码基本上是一个循环，在一个名为 PerformenceCheckTable 的表中插入一些字段。
这个测试之所以可以，是因为它只是在衡量Azure SQL的核心性能。没有额外的代码、复杂的查询、索引问题等。
在性能测试时，我首先进行验证，以确认基础性能是否稳定，以及我的平台是否运行良好。如果这样可以，我可以更深入地分析涵盖查询、索引和算法的具体功能性能。
我看到核心SQL性能低于“良好性能”的一个原因是，当有定制代码或独立软件（ISV）实际上会导致AOS崩溃时。如果崩溃发生得太频繁，我觉得可能是某种灾难恢复机制启动了，导致Azure SQL的SKU或集群变了，性能可能更差。（我们对此尚无完整见解）
所以如果你怀疑底层 SQL 平台是否有点慢，可以“ping”测试插入。
