Los hints son consejos que se le dan al optimizador SQL de Oracle para que elabore el plan de ejecución de una sentencia DML según nosotros le indicamos.
Gracias a estos hints se puede, por ejemplo, indicar al optimizador SQL de orale que trabaje de un modo u otro.
Los hints se incorporan en forma de comentario y deben ir justo detras del comando principal.
ex
SELECT /*+ HINT */ ...
SELECT /*+ ALL_ROWS */ employee_id, last_name, salary, job_id FROM employees WHERE employee_id = 7566;
SELECT /*+ FIRST_ROWS(10) */ employee_id, last_name, salary, job_id FROM employees WHERE department_id = 20;
SELECT /*+ CHOOSE */ employee_id, last_name, salary, job_id FROM employees WHERE employee_id = 7566;
SELECT /*+ RULE */ employee_id, last_name, salary, job_id FROM employees WHERE employee_id = 7566;
Hints para determinar el modo de acceso:
SELECT /*+ FULL(e) */ employee_id, last_name FROM employees e WHERE last_name LIKE :b1;
SELECT /*+ROWID(employees)*/ *
FROM employees WHERE rowid > 'AAAAtkAABAAAFNTAAA' AND employee_id = 155;
SELECT /*+ CLUSTER */ employees.last_name, department_id FROM employees, departments WHERE department_id = 10 AND employees.department_id = departments.department_id;
Vamos a considerar una consulta que recoja el nombre, altura y peso de los pacientes varones de un hospital:
SELECT name, height, weight FROM patients WHERE sex = 'm';
Imaginemos que hay un indice en la columna sex que contiene los valores de m y f. Si hay igual numero de hombre(m) que de mujeres(f) en el hospital entonces la consulta devuelve un porcentaje bastante grande de lineas y un full scan de la tabla es lo más rápido. De hecho un full scan es lo más rápido si la colsulta devuelve a partir de la mitad + 1 de las lineas de la tabla. En cambio. Si hay pocos hombres en la tabla, la búsqueda a traves de un índice es más rápida que no recorrerse toda la tabla.
Como que en una situación normal en un campo donde hay sólo dos valores posibles el optimizador de Oracle buscará por toda la tabla por defecto en vez de usar el indice para ello. Por lo que, si sabes que el numero de resultados es reducido es buena idea forzar a que use en índice para recuperarlos
SELECT /*+ INDEX(patients sex_index) usa el índice porque YO se que hay pocos hombres */ name, height, weight FROM patients WHERE sex = 'm';
The INDEX_JOIN hint explicitly instructs the optimizer to use an index join as an access path. For the hint to have a positive effect, a sufficiently small number of indexes must exist that contain all the columns required to resolve the query.
index_join_hint::= Text description of index_join_hint.gif follows Text description of the illustration index_join_hint.gif
where:
For example, the following query uses an index join to access the employee_id and department_id columns, both of which are indexed in the employees table.
SELECT /*+index_join(employees emp_emp_id_pk emp_department_ix)*/
employee_id, department_id FROM employees WHERE department_id > 50;
INDEX_DESC
The INDEX_DESC hint explicitly chooses an index scan for the specified table. If the statement uses an index range scan, then Oracle scans the index entries in descending order of their indexed values. In a partitioned index, the results are in descending order within each partition.
index_desc_hint::= Text description of index_desc_hint.gif follows Text description of the illustration index_desc_hint.gif
Each parameter serves the same purpose as in the INDEX hint. For example:
SELECT /*+ INDEX_DESC(a ord_order_date_ix) */
a.order_date, a.promotion_id, a.order_id FROM orders a
WHERE a.order_date = :b1;
INDEX_FFS
The INDEX_FFS hint causes a fast full index scan to be performed rather than a full table scan.
index_ffs_hint::= Text description of index_ffs_hint.gif follows Text description of the illustration index_ffs_hint.gif
For example:
SELECT /*+ INDEX_FFS ( o order_pk ) */ COUNT(*) FROM order_items l, orders o WHERE l.order_id > 50
AND l.order_id = o.order_id;
See Also:
“Full Scans” NO_INDEX
The NO_INDEX hint explicitly disallows a set of indexes for the specified table.
no_index_hint::= Text description of no_index_hint.gif follows Text description of the illustration no_index_hint.gif
The NO_INDEX hint applies to function-based, B-tree, bitmap, cluster, or domain indexes. If a NO_INDEX hint and an index hint (INDEX, INDEX_ASC, INDEX_DESC, INDEX_COMBINE, or INDEX_FFS) both specify the same indexes, then both the NO_INDEX hint and the index hint are ignored for the specified indexes and the optimizer considers the specified indexes.
For example:
SELECT /*+NO_INDEX(employees emp_empid)*/ employee_id FROM employees WHERE employee_id > 200;
AND_EQUAL
The AND_EQUAL hint explicitly chooses an execution plan that uses an access path that merges the scans on several single-column indexes.
and_equal_hint::= Text description of and_equal_hint.gif follows Text description of the illustration and_equal_hint.gif
where:
origenes: