因为上述指标是Oracle的度量显示的，无法直接类比到其他数据库。可以凭借专家经验+历史数据，评估负载压力。用于对其他备选技术方案进行评估的依据之一。这其中的有些指标（例如user calls等），可以转化为量化指标指导后续测试等工作。
2）评估瓶颈点对于某项指标非常突出的情况，那说明现有业务也有瓶颈，在迁移至其他方案时尽量在设计阶段就予以考虑，并在测试环节重点关注，减少可能的技术风险。
3.6 SQL语句
SQL语句的改写，是整个迁移工作中最为头疼的部分。除非是完全重构，否则是需要关注SQL改写的工作任务。这里面涉及到改写量、复杂度、性能对比等诸多内容，很多还是需要人工甄别完成。
笔者曾经有过这样的经验，项目组花1个月的时间就完成某项目的“结构+SQL”的迁移工作，但是后续又花费了3个月的时间完成语句优化、甚至结构调整。其原因是迁移上线后语句无法满足性能需求。而这是在边上线、边调整，过程异常痛苦。因此早期查明现有SQL情况，对于评估工作量、改写难度、性能评估，有着重要的意义。而上面这部分就是收集了分析用户在历史的所有SQL（可以打开明细开关，显示全量SQL），其包含了以下这些维度。
1）总SQL数该指标可近似反映业务繁忙程度。此外，也可用于后续有问题语句的比例分析基础。
2）超长SQL这里列出了超过指定字符数的语句，阀值在可通过参数进行配置。如果是考虑MySQL，建议使用“短小精悍”的SQL，面对复杂SQL则一般表现不佳。那么对于这些超长的语句，都是值得关注的对象，起码是容易出现问题的语句。
3）ANTI SQL反向查询，数据库处理上都较为困难，这部分也比较考验优化器。虽然在MySQL的较新版本中，对反向查询有了不错的优化，但这部分仍然值得关注。
4）Oracle Syntax SQL有Oracle特征的写法，即Oracle的方言（例如特有函数、伪列等），这些都是需要在迁移中进行处理的。当然现在也有的厂商，宣布其产品是兼容Oracle语法的，但也建议针对这些做专门测试。
5）Join 3+ Table SQL多表关联，也是比较考验优化器。特别是MySQL表间关联效率偏低，不建议使用超过2个以上表的关联。这里列出的是3个及以上的关联查询，需要考虑修改。针对特别复杂的查询，可以考虑将其卸载到大数据平台完成。
6）SubQuery SQL子查询情况类似上面，也是MySQL不擅长的。虽然优化器可在一定程度上进行优化，但还是值得关注。