Características de procesamiento de consultas inteligentes en detalle

Se aplica a:SQL ServerAzure SQL DatabaseInstancia administrada de Azure SQLBase de datos SQL en Microsoft Fabric

Este artículo contiene descripciones detalladas de varias características de procesamiento de consultas inteligentes (IQP), notas de la versión y más detalles. La familia de características de procesamiento de consultas inteligentes incluye características con un gran impacto que mejoran el rendimiento de las cargas de trabajo existentes con un esfuerzo de implementación mínimo.

Puede hacer que las cargas de trabajo sean aptas automáticamente para el procesamiento de consultas inteligentes si habilita el nivel de compatibilidad de base de datos pertinente en la base de datos. Puede establecerlo con Transact-SQL. Por ejemplo, para establecer el nivel de compatibilidad de una base de datos en SQL Server 2022 (16.x):

ALTER DATABASE [WideWorldImportersDW]
    SET COMPATIBILITY_LEVEL = 160;

Para obtener más información sobre los cambios introducidos con las nuevas versiones, consulte:

Combinaciones adaptables en modo por lotes

Se aplica a: SQL Server (a partir de SQL Server 2017 (14.x)), Azure SQL Database

La característica Uniones adaptables del modo por lotes permite posponer la elección de un método de Hash Join o Nested Loops Join hasta después de que se haya examinado la primera entrada de datos, usando un único plan almacenado en caché. El operador de combinaciones adaptables define un umbral que se usa para decidir cuándo cambiar a un plan de bucles anidados. Por tanto, el plan puede cambiar dinámicamente a una estrategia de unión mejor durante la ejecución.

Para más información, incluido cómo deshabilitar las combinaciones adaptables sin cambiar el nivel de compatibilidad, vea Descripción de las combinaciones adaptables.

Ejecución intercalada de MSTVF

Se aplica a: SQL Server (a partir de SQL Server 2017 (14.x)), Azure SQL Database

Una función con valores de tabla de varias instrucciones (MSTVF) es un tipo de función definida por el usuario que puede aceptar parámetros, ejecutar varias instrucciones T-SQL y RETURN en una tabla.

La ejecución intercalada ayuda con los problemas de rendimiento de las cargas de trabajo debidos a las estimaciones de cardinalidad fijas asociadas a las MSTVF. Con la ejecución intercalada, se utiliza el número real de filas que devuelve la función para tomar decisiones mejor fundamentadas en fases posteriores del plan de consulta.

Las MSTVF tienen una estimación de cardinalidad fija de 100 a partir de SQL Server 2014 (12.x), y de 1 en versiones anteriores de SQL Server.

La ejecución intercalada cambia el límite unidireccional entre las fases de optimización y ejecución de una ejecución de una sola consulta y permite que los planes se adapten en función de las estimaciones de cardinalidad revisadas. Durante la optimización, si el motor de base de datos encuentra un candidato para la ejecución intercalada que utiliza funciones con valores de tabla de varias instrucciones (MSTVF), la optimización se pausa, se ejecuta el subárbol aplicable, se capturan estimaciones precisas de cardinalidad, y luego se reanuda la optimización para las operaciones posteriores.

En la imagen siguiente se muestran los resultados de estadísticas de consultas dinámicas, un subconjunto de un plan de ejecución global que refleja el impacto de las estimaciones de cardinalidad fijas de las MSTVF.

Puede ver el flujo real de filas frente a las filas estimadas. Hay tres áreas reseñables del plan (el flujo va de derecha a izquierda):

  • La exploración de tabla de MSTVF tiene una estimación fija de 100 filas. Pero en este ejemplo hay 527.597 filas que pasan por este recorrido de tabla de MSTVF, como se muestra en las estadísticas de consultas dinámicas a través de 527597 de 100 reales de estimados, por lo que la estimación fija está considerablemente desviada.
  • En el caso de la operación de bucles anidados, se supone que el lado externo de la combinación solo devuelve 100 filas. Dado el gran número de filas que devuelve el MSTVF, es probable que sea mejor utilizar un algoritmo de combinación diferente.
  • En el caso de la operación de coincidencia de hash, observe el pequeño símbolo de advertencia, que en este caso indica un desbordamiento en el disco.

Diagrama del flujo de filas del plan de ejecución frente a las filas estimadas.

Compare el plan anterior con el plan real generado con la ejecución intercalada habilitada:

Diagrama de un plan de ejecución intercalado.

  • El examen de la tabla MSTVF ahora refleja una estimación de cardinalidad precisa. Fíjese también en el reordenamiento de este escaneo de tabla y de las demás operaciones.
  • Con respecto a los algoritmos de combinación, se ha pasado de una operación de bucle anidado a una operación de coincidencia de hash, que es más adecuada dado el gran número de filas implicadas.
  • Observe además que ya no tenemos advertencias de derrame, ya que se asigna más memoria en función del número real de filas que proviene del examen de la tabla MSTVF.

Sentencias aptas para ejecución intercalada

Las instrucciones que hacen referencia a las funciones MSTVF en la ejecución intercalada actualmente deben ser de solo lectura y no formar parte de una operación de modificación de datos. Además, las MSTVF no son aptas para la ejecución intercalada si no usan constantes en tiempo de ejecución.

Ventajas de la ejecución intercalada

En general, cuanta mayor sea la distorsión entre el número de filas real y el estimado, además del número de operaciones de nivel inferior del plan, mayor será el impacto sobre el rendimiento.

En general, la ejecución intercalada beneficia a las consultas en las que:

  • Hay una gran asimetría entre el número estimado y real de filas para el conjunto de resultados intermedio (en este caso, el MSTVF).

  • Y la consulta global es sensible a un cambio en el tamaño del resultado intermedio. Esto suele ocurrir cuando hay un árbol complejo por encima de ese subárbol en el plan de consulta.

    Un elemento básico SELECT * de MSTVF no se beneficia de la ejecución intercalada.

Sobrecarga de ejecución intercalada

La sobrecarga debe ser de mínima a ninguna. Las MSTVF ya se materializaban antes de la introducción de la ejecución intercalada; sin embargo, la diferencia es que ahora permitimos la optimización diferida y luego utilizamos la estimación de cardinalidad del conjunto materializado de filas. Como ocurre con cualquier plan afectado por cambios, algunos planes podrían cambiar de tal forma que, aun con una mejor cardinalidad para el subárbol, acabemos obteniendo un plan peor para la consulta en su conjunto. La mitigación puede incluir revertir el nivel de compatibilidad o usar Almacén de consultas para forzar la versión del plan que no ha sufrido regresión.

Ejecución intercalada y ejecuciones consecutivas

Una vez que se almacena en caché un plan de ejecución intercalado, el plan con las estimaciones revisadas de la primera ejecución se usa para ejecuciones consecutivas sin volver a activar la ejecución intercalada.

Realice un seguimiento de la actividad de ejecución entrelazada

Puede ver los atributos de uso en el plan de ejecución de consulta real:

Atributo del plan de ejecución Description
ContainsInterleavedExecutionCandidates Se aplica al nodo QueryPlan. Si true, significa que el plan contiene candidatos de ejecución entrelazada.
IsInterleavedExecuted Atributo del elemento RuntimeInformation dentro de RelOp para el nodo TVF. Si es true, significa que la operación se ha materializado como parte de una operación de ejecución intercalada.

También puede hacer un seguimiento de los casos de ejecución intercalada mediante los siguientes eventos extendidos:

XEvent Description
interleaved_exec_status Este evento se desencadena cuando se está produciendo la ejecución intercalada.
interleaved_exec_stats_update Este evento describe las estimaciones de cardinalidad actualizadas por la ejecución intercalada.
Interleaved_exec_disabled_reason Este evento se dispara cuando una consulta con un posible candidato para la ejecución intercalada no obtiene en realidad la ejecución intercalada.

Se debe ejecutar una consulta para permitir que la ejecución intercalada revise las estimaciones de cardinalidad de MSTVF. Sin embargo, el plan de ejecución estimado sigue mostrando cuándo hay candidatos para ejecución intercalada mediante el atributo showplan de ContainsInterleavedExecutionCandidates.

Almacenamiento en caché de la ejecución entrelazada

Si un plan se borra o se expulsa de la memoria caché, tras la ejecución de la consulta hay una compilación nueva que usa la ejecución intercalada. Una instrucción con OPTION (RECOMPILE) crea un plan con ejecución intercalada y no lo almacena en la memoria caché.

Ejecución intercalada e interoperabilidad del Almacén de consultas

Los planes que utilizan la ejecución intercalada se pueden forzar. El plan es la versión que ha corregido las estimaciones de cardinalidad basándose en la ejecución inicial.

Deshabilitar la ejecución intercalada sin cambiar el nivel de compatibilidad

La ejecución intercalada se puede deshabilitar en el nivel de base de datos o de instrucción sin dejar de mantener el nivel de compatibilidad de la base de datos 140 o superior. Para deshabilitar la ejecución intercalada para todas las ejecuciones de consultas que se originan en la base de datos, ejecute lo siguiente en el contexto de la base de datos aplicable:

-- SQL Server 2017
ALTER DATABASE SCOPED CONFIGURATION SET DISABLE_INTERLEAVED_EXECUTION_TVF = ON;

-- Starting with SQL Server 2019, and in Azure SQL Database
ALTER DATABASE SCOPED CONFIGURATION SET INTERLEAVED_EXECUTION_TVF = OFF;

Cuando está habilitada, esta configuración aparece como habilitada en sys.database_scoped_configurations. Para volver a habilitar la ejecución intercalada para todas las ejecuciones de consultas que se originan en la base de datos, ejecute lo siguiente en el contexto de la base de datos aplicable:

-- SQL Server 2017
ALTER DATABASE SCOPED CONFIGURATION SET DISABLE_INTERLEAVED_EXECUTION_TVF = OFF;

-- Starting with SQL Server 2019, and in Azure SQL Database
ALTER DATABASE SCOPED CONFIGURATION SET INTERLEAVED_EXECUTION_TVF = ON;

También puede deshabilitar la ejecución intercalada para una consulta específica si designa DISABLE_INTERLEAVED_EXECUTION_TVF como una sugerencia de consulta USE HINT. Por ejemplo:

SELECT [fo].[Order Key],
       [fo].[Quantity],
       [fol].[OutlierEventQuantity]
FROM [Fact].[Order] AS [fo]
     INNER JOIN [Fact].[WhatIfOutlierEventQuantity]('Mild Recession', '1-01-2013', '10-15-2014') AS [fol]
         ON [fo].[Order Key] = [fol].[Order Key]
        AND [fo].[City Key] = [fol].[City Key]
        AND [fo].[Customer Key] = [fol].[Customer Key]
        AND [fo].[Stock Item Key] = [fol].[Stock Item Key]
        AND [fo].[Order Date Key] = [fol].[Order Date Key]
        AND [fo].[Picked Date Key] = [fol].[Picked Date Key]
        AND [fo].[Salesperson Key] = [fol].[Salesperson Key]
        AND [fo].[Picker Key] = [fol].[Picker Key]
OPTION (USE HINT('DISABLE_INTERLEAVED_EXECUTION_TVF'));

Una sugerencia de consulta USE HINT tiene prioridad sobre una configuración con ámbito de base de datos o una configuración de marca de seguimiento.

Inserción en línea de UDF escalares

Se aplica a: SQL Server (a partir de SQL Server 2019 (15.x)), Azure SQL Database

La inserción de UDF escalar transforma automáticamente las UDF escalares en expresiones relacionales. Las inserta en la consulta SQL de llamada. Esta transformación mejora el rendimiento de las cargas de trabajo que aprovechan las UDF escalares. La inserción en línea de UDF escalares facilita la optimización basada en costes de las operaciones dentro de las UDF. Los resultados son eficaces, orientados a conjuntos y paralelos en lugar de tratarse de planes de ejecución seriales, iterativos e ineficaces. Esta característica está habilitada de forma predeterminada en el nivel 150 o superior de compatibilidad de base de datos.

Para obtener más información, vea Inserción de UDF escalares.

Compilación diferida de variables de tabla

Se aplica a: SQL Server (a partir de SQL Server 2019 (15.x)), Azure SQL Database

La compilación diferida de variables de tabla mejora la calidad del plan y el rendimiento general de las consultas que hacen referencia a las variables de tabla. Durante la optimización y el plan de compilación inicial, esta característica propaga las estimaciones de cardinalidad que se basan en los recuentos de filas de variables de tabla reales. Esta información exacta del recuento de filas se utiliza para optimizar las operaciones del plan en etapas posteriores.

Con la compilación diferida de variables de tabla, la compilación de una instrucción que hace referencia a una variable de tabla se aplaza hasta la primera ejecución real de esta. Este comportamiento de compilación diferida es idéntico al comportamiento de las tablas temporales. Este cambio da lugar al uso de la cardinalidad real en lugar de la estimación original de una sola fila.

Para habilitar la compilación diferida de variables de tabla, habilite el nivel 150 o superior de compatibilidad de base de datos para la base de datos a la que está conectado cuando se ejecuta la consulta.

La compilación diferida de variables de tabla no cambia ninguna otra característica de las variables de tabla. Por ejemplo, esta característica no agrega estadísticas de columna a las variables de tabla.

La compilación diferida de variables de tabla no aumenta la frecuencia de recompilación. En su lugar, se desplaza a donde se produce la compilación inicial. El plan en caché resultante se genera a partir del recuento inicial de filas de la variable de tabla de compilación diferida. El plan almacenado en caché se reutiliza en consultas consecutivas. Se reutiliza hasta que el plan se descarta o se recompila.

Un recuento de filas de una variable de tabla que se utiliza para la compilación inicial del plan representa un valor típico, que podría ser diferente de una estimación fija de recuento de filas. Si es diferente, las operaciones aguas abajo se benefician. Si el recuento de filas de variables de tabla varía considerablemente entre ejecuciones, podría ser que esta característica no mejore el rendimiento.

Deshabilitación de la compilación diferida de variables de tabla sin cambiar el nivel de compatibilidad

Deshabilite la compilación diferida de las variables de tabla en el nivel de base de datos o de instrucción, sin dejar de mantener el nivel de compatibilidad de la base de datos 150 o superior. Para deshabilitar la compilación diferida de variables de tabla para todas las ejecuciones de consultas que se originan en la base de datos, ejecute el siguiente ejemplo en el contexto de la base de datos aplicable:

ALTER DATABASE SCOPED CONFIGURATION SET DEFERRED_COMPILATION_TV = OFF;

Para volver a habilitar la compilación diferida de variables de tabla para todas las ejecuciones de consultas que se originan en la base de datos, ejecute el siguiente ejemplo en el contexto de la base de datos aplicable:

ALTER DATABASE SCOPED CONFIGURATION SET DEFERRED_COMPILATION_TV = ON;

También puede deshabilitar la compilación diferida de variables de tabla para una consulta específica mediante la designación de DISABLE_DEFERRED_COMPILATION_TV como una sugerencia de consulta USE HINT. Por ejemplo:

DECLARE @LINEITEMS TABLE (
    L_OrderKey INT NOT NULL,
    L_Quantity INT NOT NULL);

INSERT @LINEITEMS
SELECT L_OrderKey,
       L_Quantity
FROM dbo.lineitem
WHERE L_Quantity = 5;

SELECT O_OrderKey,
       O_CustKey,
       O_OrderStatus,
       L_QUANTITY
FROM ORDERS, @LINEITEMS
WHERE O_ORDERKEY = L_ORDERKEY
      AND O_OrderStatus = 'O'
OPTION (USE HINT('DISABLE_DEFERRED_COMPILATION_TV'));

Optimización del plan de sensibilidad de parámetros

Se aplica a: SQL Server 2022 (16.x) y versiones posteriores de Azure SQL DatabaseAzure SQL Managed Instance

La optimización del plan de sensibilidad de parámetros (PSP) forma parte de la familia de funcionalidades de procesamiento inteligente de consultas. Aborda el escenario en el que un único plan almacenado en caché para una consulta con parámetros no es óptimo para todos los posibles valores de parámetros entrantes. Este es el caso de las distribuciones de datos no uniformes.

Procesamiento de consultas aproximado

El procesamiento de consultas aproximado es una nueva familia de características. Agrega conjuntos de datos de gran tamaño en los que la capacidad de respuesta resulta más fundamental que la precisión absoluta. Un ejemplo es calcular un COUNT(DISTINCT()) en 10 mil millones de filas para su visualización en un panel. En este caso, la precisión absoluta no es importante, pero la capacidad de respuesta es fundamental.

Recuento aproximado de valores distintos

Se aplica a: SQL Server (a partir de SQL Server 2019 (15.x)), Azure SQL Database

La función de agregado APPROX_COUNT_DISTINCT nueva devuelve el número aproximado de valores no nulos únicos de un grupo.

Esta característica está disponible a partir de SQL Server 2019 (15.x), independientemente del nivel de compatibilidad.

Para obtener más información, consulte APPROX_COUNT_DISTINCT.

Percentil aproximado

Se aplica a: SQL Server (a partir de SQL Server 2022 (16.x)), Azure SQL Database

Estas funciones agregadas calculan percentiles para un gran conjunto de datos con márgenes de error aceptables basados en rangos, para ayudar a tomar decisiones rápidas mediante el uso de funciones agregadas de percentiles aproximados.

Para obtener más información, consulte APPROX_PERCENTILE_DISC y APPROX_PERCENTILE_CONT

Modo por lotes en el almacén de filas

Se aplica a: SQL Server (a partir de SQL Server 2019 (15.x)), Azure SQL Database

El modo por lotes en el almacén de filas permite la ejecución en modo por lotes de las cargas de trabajo de análisis sin necesidad de índices de almacén de columnas. Esta característica admite la ejecución en modo por lotes y filtros de mapa de bits para montones en disco e índices de árbol B. El modo por lotes en el almacenamiento por filas permite admitir todos los operadores existentes habilitados para el modo por lotes.

Las consultas existentes que más pueden beneficiarse del modo por lotes en rowstore incluyen:

  • Combinaciones hash entre tablas grandes con almacenamiento por filas
  • Consultas con GROUP BY sobre muchos valores distintos
  • Funciones de agregado como SUM, COUNT, MIN, , MAX, AVG
  • Consultas de funciones de ventana con OVER, PARTITION BYy ORDER BY, incluidas las funciones de agregado, ROW_NUMBER y RANK

Para obtener más información sobre el rendimiento de las funciones de ventana, vea Consideraciones de rendimiento en la referencia de cláusulas OVER .

Note

La documentación utiliza el término árbol B generalmente en referencia a los índices. En los índices rowstore, el Motor de base de datos implementa un árbol B+. Esto no se aplica a los índices de almacén de columnas ni a los índices de tablas optimizadas para memoria. Para obtener más información, consulte la guía de diseño y arquitectura de índices de SQL Server y Azure SQL.

Información general sobre la ejecución del modo por lotes

SQL Server 2012 (11.x) introdujo una nueva característica para acelerar las cargas de trabajo de análisis: los índices de almacén de columnas. Los casos de uso y el rendimiento de los índices de almacén de columnas aumentaron en cada versión posterior de SQL Server. La creación de índices de almacén de columnas en tablas puede mejorar el rendimiento de las cargas de trabajo analíticas. Sin embargo, hay dos conjuntos diferentes de tecnologías, aunque guardan relación:

  • Con los índices de almacén de columnas, las consultas analíticas tienen acceso solo a los datos de las columnas que necesitan. La compresión de página en formato de almacén de columnas también es más eficaz que la compresión en los índices de almacén de filas tradicionales.
  • Con el procesamiento de modo por lotes, los operadores de consulta procesan los datos con mayor eficacia. Funcionan en un lote de filas en lugar de una fila cada vez. Muchas otras mejoras de escalabilidad están vinculadas al procesamiento por lotes. Para obtener más información sobre el modo por lotes, consulte Modos de ejecución.

Los dos conjuntos de características funcionan conjuntamente para mejorar la utilización de entrada y salida (E/S) y CPU:

  • Al usar índices de almacén de columnas, una mayor parte de sus datos cabe en memoria. Esto reduce la carga de trabajo de E/S.
  • El proceso en modo por lotes utiliza la CPU de manera más eficaz.

Las dos tecnologías se apoyan entre sí siempre que es posible. Por ejemplo, las agregaciones en modo por lotes pueden evaluarse como parte del examen de un índice de almacén de columnas. Asimismo, los datos comprimidos de almacenamiento por columnas se procesan de forma mucho más eficiente mediante la codificación por longitud de secuencia con uniones en modo por lotes y agregaciones en modo por lotes.

Sin embargo, es importante comprender que las dos características son independientes:

  • Puede obtener planes en modo fila que usan índices de almacén de columnas.
  • Puede obtener planes en modo por lotes que usan solo índices rowstore.

Normalmente obtiene los mejores resultados al usar las dos características conjuntamente. Antes de SQL Server 2019 (15.x), el optimizador de consultas de SQL Server consideraba el procesamiento en modo por lotes solo para las consultas que implicaban al menos una tabla con un índice de almacén de columnas.

Podría ser que los índices de almacén de columnas no sean adecuados para algunas aplicaciones. Una aplicación podría usar cualquier otra característica no compatible con los índices de almacén de columnas. Por ejemplo, las modificaciones en su lugar no son compatibles con la compresión por almacenamiento en columnas. Por tanto, los desencadenadores no se admiten en tablas con índices de almacén de columnas agrupados. Y lo que es más importante, los índices de almacén de columnas agregan sobrecarga a las instrucciones DELETE y UPDATE.

Para algunas cargas de trabajo híbridas transaccionales y analíticas, la sobrecarga de una carga de trabajo transaccional supera las ventajas que se obtienen al usar índices de almacén de columnas. Estos escenarios pueden beneficiarse de un mejor uso de la CPU empleando únicamente el procesamiento por lotes. Por eso, la función de modo por lotes sobre rowstore evalúa el uso del modo por lotes para todas las consultas, independientemente del tipo de índices involucrados.

Cargas de trabajo que podrían beneficiarse del modo por lotes en rowstore

Las siguientes cargas de trabajo pueden beneficiarse del modo por lotes en rowstore:

  • una parte significativa de la carga de trabajo consta de consultas analíticas. Normalmente, estas consultas usan operadores como combinaciones o agregados que procesan cientos de miles de filas o más.
  • La carga de trabajo está enlazada a la CPU. Si el cuello de botella es de E/S, se recomienda considerar un índice de almacén de columnas, siempre que sea posible.
  • La creación de un índice de almacén de columnas agrega demasiada sobrecarga al elemento transaccional de su carga de trabajo. O bien, la creación de un índice de almacén de columnas no es factible porque la aplicación depende de una característica que aún no se admite con índices de almacén de columnas.

Note

El modo por lotes en rowstore solo ayuda al reducir el consumo de CPU. Si el cuello de botella está relacionado con E/S y los datos aún no están almacenados en caché (caché "fría"), el modo por lotes en el rowstore no mejora el tiempo de ejecución de la consulta. Del mismo modo, si no hay memoria suficiente en la máquina para almacenar en caché todos los datos, es poco probable que se produzca una mejora del rendimiento.

¿Qué cambios se producirán con el modo por lotes en el almacén de filas?

El modo por lotes en rowstore requiere que la base de datos tenga el nivel de compatibilidad 150.

Incluso si una consulta no tiene acceso a ninguna tabla con índices de almacén de columnas, el procesador de consultas usa heurística para decidir si se debe considerar el modo por lotes. La heurística consiste en estas comprobaciones:

  1. Una comprobación inicial de tamaños de tablas, operadores utilizados y cardinalidades estimadas en la consulta de entrada.
  2. Puntos de control adicionales, a medida que el optimizador detecta planes nuevos y más baratos para la consulta. Si estos planes alternativos no hacen un uso considerable del modo por lotes, el optimizador dejará explorar alternativas al modo por lotes.

Si se usa el modo por lotes en rowstore, verá el modo de ejecución real como modo por lotes en el plan de consulta. El operador de exploración usa el modo por lotes para montones almacenados en disco e índices de árbol B. Esta exploración del modo por lotes puede evaluar los filtros de mapa de bits del modo por lotes. También podría ver otros operadores del modo por lotes en el plan. Entre los ejemplos se incluyen combinaciones por hash, agregados basados en hash, ordenaciones, agregados de ventana, filtros, concatenación y operadores escalares calculados.

Remarks

Los planes de consulta no siempre usan el modo por lotes. Es posible que el optimizador de consultas decida que el modo por lotes no es beneficioso para la consulta.

El espacio de búsqueda del optimizador de consultas está cambiando. Así pues, si obtiene un plan de modo de fila, podría no ser igual al plan obtenido en un nivel de compatibilidad más bajo. Y si obtienes un plan en modo por lotes, puede que no sea el mismo que el que obtienes con un índice columnstore.

Los planes también pueden cambiar para las consultas que combinan los índices de almacén de columnas y de almacén de filas como consecuencia de una nueva exploración del almacén de filas en modo por lotes.

Existen limitaciones actuales para el nuevo modo por lotes en la exploración del almacenamiento por filas:

  • No se aplicará a las tablas OLTP en memoria ni a ningún índice que no sea un montón en disco o un árbol B.
  • Tampoco se iniciará si se captura o se filtra una columna de objetos de gran tamaño (LOB). Esta limitación incluye conjuntos de columnas dispersas y columnas XML.

Hay consultas en las que no se utiliza el modo por lotes incluso con índices de almacenamiento por columnas. Entre los ejemplos se incluyen consultas que implican cursores. Estas mismas exclusiones también se aplican al modo por lotes en el almacenamiento por filas.

Configuración del modo por lotes en el almacén de filas

La BATCH_MODE_ON_ROWSTOREconfiguración de ámbito de base de datos está activada de forma predeterminada.

Puede deshabilitar el modo por lotes en el almacén de filas sin cambiar el nivel de compatibilidad de la base de datos:

-- Disabling batch mode on rowstore
ALTER DATABASE SCOPED CONFIGURATION SET BATCH_MODE_ON_ROWSTORE = OFF;

-- Enabling batch mode on rowstore
ALTER DATABASE SCOPED CONFIGURATION SET BATCH_MODE_ON_ROWSTORE = ON;

Puede deshabilitar el modo por lotes en rowstore mediante la configuración de ámbito de base de datos. Pero aún puede anular la configuración a nivel de consulta usando la sugerencia de consulta ALLOW_BATCH_MODE. El ejemplo siguiente habilita el modo por lotes en el almacenamiento por filas aunque la característica esté deshabilitada mediante la configuración con ámbito de base de datos:

SELECT [Tax Rate],
       [Lineage Key],
       [Salesperson Key],
       SUM(Quantity) AS SUM_QTY,
       SUM([Unit Price]) AS SUM_BASE_PRICE,
       COUNT(*) AS COUNT_ORDER
FROM Fact.OrderHistoryExtended
WHERE [Order Date Key] <= DATEADD(dd, -73, '2015-11-13')
GROUP BY [Tax Rate], [Lineage Key], [Salesperson Key]
ORDER BY [Tax Rate], [Lineage Key], [Salesperson Key]
OPTION (RECOMPILE, USE HINT('ALLOW_BATCH_MODE'));

También puede deshabilitar el modo por lotes en rowstore para una consulta específica usando la sugerencia de consulta DISALLOW_BATCH_MODE. Observe el ejemplo siguiente:

SELECT [Tax Rate],
       [Lineage Key],
       [Salesperson Key],
       SUM(Quantity) AS SUM_QTY,
       SUM([Unit Price]) AS SUM_BASE_PRICE,
       COUNT(*) AS COUNT_ORDER
FROM Fact.OrderHistoryExtended
WHERE [Order Date Key] <= DATEADD(dd, -73, '2015-11-13')
GROUP BY [Tax Rate], [Lineage Key], [Salesperson Key]
ORDER BY [Tax Rate], [Lineage Key], [Salesperson Key]
OPTION (RECOMPILE, USE HINT('DISALLOW_BATCH_MODE'));

Funcionalidades de retroalimentación sobre el procesamiento de consultas

Las funcionalidades de retroalimentación del procesamiento de consultas forman parte de la familia de funcionalidades de procesamiento inteligente de consultas.

Los comentarios de procesamiento de consultas son un proceso por el que el procesador de consultas de SQL Server, Azure SQL Database y Azure SQL Managed Instance usa datos históricos sobre la ejecución de una consulta para decidir si esta puede recibir ayuda de uno o varios cambios en la forma en que se compila y ejecuta. Los datos de rendimiento se recopilan en el Almacén de consultas, con varias sugerencias para mejorar la ejecución de consultas. Si se realiza correctamente, guardamos estas modificaciones de forma persistente en disco, en memoria y/o en Almacén de consultas para su uso futuro. Si las sugerencias no producen una mejora suficiente, se descartan y la consulta continúa ejecutándose sin esos comentarios.

Para obtener información sobre qué características de comentarios de procesamiento de consultas están disponibles en distintas versiones de SQL Server o en base de datos de Azure SQL o en la Azure SQL Managed Instance, consulte Procesamiento de consultas inteligentes en bases de datos SQL o en los siguientes artículos para cada característica de comentarios.

Retroalimentación de concesión de memoria

La retroalimentación de concesión de memoria se ha incorporado progresivamente en las últimas versiones principales de SQL Server.

Retroalimentación sobre la asignación de memoria en modo por lotes

Para obtener información sobre la retroalimentación sobre la concesión de memoria del modo por lotes, visite Retroalimentación sobre la concesión de memoria del modo por lotes.

Retroalimentación sobre la asignación de memoria en modo de fila

Para obtener información sobre la retroalimentación de concesión de memoria en modo de filas, visite Retroalimentación de concesión de memoria en modo de filas.

Retroalimentación de concesión de memoria en modo percentil y modo de persistencia

Para obtener información sobre los comentarios de concesión de memoria en modo percentil y persistencia, visite Comentarios de concesión de memoria en modo percentil y modo de persistencia.

Comentarios de grado de paralelismo (DOP)

Para obtener información sobre la retroalimentación de DOP, visite Retroalimentación sobre el grado de paralelismo (DOP).

Retroalimentación sobre la estimación de cardinalidad (CE)

Para obtener información sobre los comentarios de CE, visite Comentarios de estimación de cardinalidad (CE).

Forzado de planes optimizado con Almacén de consultas

Para obtener información sobre el forzado de planes optimizado con Almacén de consultas, consulte Forzado de planes optimizado con Almacén de consultas.

Contenido relacionado

  • Last updated on