1. Antecedentes
Cuando sql optimiza, a menudo usamos planes de ejecución, como Navicat o plsql explica planes. De hecho, el resultado es solo un valor estimado, por lo que hará que el entorno de prueba se ejecute rápidamente y el entorno de producción sea lento.
Como se muestra abajo:
El plan de ejecución obtenido usando AUTOTRACE o EXPLAIN PLAN FOR proviene de PLAN_TABLE. PLAN_TABLE es una tabla temporal a nivel de sesión, el plan de ejecución en el interior no es el plan de ejecución real de SQL, solo es estimado por el optimizador.
El plan de ejecución real no debe estimarse, debe ejecutarse realmente. El plan de ejecución ejecutado SQL existe en el pool compartido, específicamente en el diccionario de datos VS QLPLAN, el plan de ejecución con A - T ime viene de V SQL_PLAN, el plan de ejecución con A-Time viene de VSQLPLAN, con El plan de ejecución con A- El tiempo proviene de VSQL_PLAN, que es el plan de ejecución real, y el plan de ejecución obtenido a través de AUTOTRACE y EXPLAIN PLAN FOR es solo el plan de ejecución estimado por el optimizador. (Nota 1)
2. Entonces, ¿cómo obtener el plan de ejecución real?
Primero, debe tener acceso a la vista de rendimiento dinámico, puede usar la siguiente declaración para autorizar
grant select any dictionary to QAS_R_BIZ;
Después de tener la autoridad, divida en los siguientes pasos para continuar (no es necesario el superadministrador)
2.1 Ejecute la siguiente declaración
alter session set statistics_level = all;
(Este paso es válido para la ventana de sesión actual, se puede omitir, se explica a continuación)
2.2 Ejecute el sql a optimizar;
select /* gather_plan_statistics */ R.RU_ID AS ruId,
R.MU_ID AS muId,
R.RU_NAME AS ruShortName,
D.YW_DM AS YWDM,
D.yws AS YWDMCOUNT
from T_REGIONAL_UNIT r
LEFT JOIN T_MANAGE_UNIT m
on r.MU_ID = m.MU_ID
left join (select YW_DM, sum(YW_DM_COUNT) as yws, SWJGDM
from T_DAILY_SELF_SERVICE_HALL_YWS
where SNAPSHOT_DATE between
TO_DATE('2020-01-14 00:00:00', 'YYYY-MM-DD HH24:MI:SS') AND
TO_DATE('2020-12-14 00:00:00', 'YYYY-MM-DD HH24:MI:SS')
group by YW_DM, SWJGDM) D
on m.MU_CODE = D.SWJGDM
where 1 = 1
and r.parent_ID = 10000
order by r.display_index, D.YW_DM
Si no realiza el paso anterior, debe agregar / + collect_plan_statistics / en la declaración.
2.3 Averigüe el ID de SQL de la sentencia ejecutada, por ejemplo:
select * from v$sql where sql_text like '%gather_plan_statistics%'
El resultado es el siguiente
2.4 Descubra el plan de ejecución basado en SQL ID
select * from table (dbms_xplan.display_cursor ('3ayyrp8bkzmb6', null, 'allstats last')); El
efecto es el siguiente,
Cópielo y péguelo en el bloc de notas ++, para mostrar todos los resultados de la consulta, recuerde hacer clic en el botón Obtener última página, haga clic en la esquina superior izquierda para seleccionar todo.
Pegar en el bloc de notas o el bloc de notas ++, el efecto es el siguiente
Puede ver que hay más campos como A-Rows y A-Time.
Starts representa el número de ejecuciones de esta operación.
E-Rows representa el número de filas estimadas por el optimizador. Es decir, filas en el plan de ejecución ordinario.
A-Rows representa el número real de filas.
A-Time representa el total acumulado hora. A diferencia del plan de ejecución ordinario, el Time en el plan de ejecución ordinario es falso, mientras que el A-Time es real.
Buffers significa lecturas lógicas acumuladas.
Lecturas significa lecturas físicas acumuladas. El
plan de ejecución real proporciona información real sobre la ejecución de SQL, incluyendo A-Time (tiempo real), A-Rows (número de fila real), Starts (tiempos de ejecución de pasos), etc. Para los desarrolladores que no son de bases de datos, es muy intuitivo y conveniente.
