sql统计在数据库性能分析中扮演着关键角色，主要包括以下几个方面的排序：
- 按运行时间排序的SQL：该排序依据是SQL语句在监控范围内的总执行时间（Elapsed Time），而不是单次执行的时间。Elapsed Time包括CPU时间和等待时间。报告中显示了占总数据库时间的百分比（%Total DB Time），CPU占比（%CPU），以及用户I/O等待时间占比（%IO）。这里特别关注执行次数和平均每次运行时间，尤其是那些平均运行时间较长的SQL，因为它们通常是CPU和I/O消耗的主要来源。
- 按CPU时间排序的SQL：此排序展示了在监控范围内占用CPU时间最长的SQL。报告中同样包括了CPU占比和I/O占比。重点关注的是每次执行的CPU时间（CPU per Exec）和CPU占比。
- 按用户I/O等待时间排序的SQL：排序基于SQL在监控范围内的总用户I/O等待时间。重点关注的是每次执行的用户I/O等待时间（UIO per Exec）和I/O占比，通常与会话堵塞和全表扫描有关。
- 按Gets排序的SQL：此排序展示了在监控范围内占用buffer gets（逻辑I/O）最多的SQL。关注点包括每次执行的Gets数量（Gets per Exec）、CPU占比和I/O占比。Gets是衡量SQL性能的主要指标之一。
- 按读取排序的SQL：此排序基于SQL在监控范围内的总物理读（物理I/O）次数。过高的物理读次数可能导致数据库性能下降，解决方案包括SQL优化、增加SGA大小、调整_small_table_threshold等。
- 按物理读取排序的SQL（未优化）：此排序展示了未优化物理读取的SQL。未优化读请求是物理读请求减去优化读请求。该指标主要适用于Exadata系统，对于其他系统没有参考意义。
- 按执行排序的SQL：此排序展示了在监控范围内执行次数最多的SQL。关注执行次数、每次执行的行数、运行时间、CPU占比和I/O占比。
- 按解析调用排序的SQL：此排序展示了在监控范围内解析次数最多的SQL。解析次数过多可能导致性能问题，特别是当解析次数大于执行次数时。
- 按共享内存排序的SQL：此排序展示了占用library cache内存最多的SQL。关注点是占用的共享内存大小（Sharable Mem）。
- 按版本计数排序的SQL：此排序展示了打开子游标数量最多的SQL。版本计数高可能导致库缓存锁定等问题。
- SQL文本的完整列表：提供所有SQL语句的详细文本信息，便于进一步分析和调优。
总体来看，SQL统计从多个维度列出了系统中执行较慢的SQL，用户可以通过点击详情获取更多信息，并利用执行计划进行SQL优化。
