Compartir a través de

Características de procesamiento de consultas inteligentes en detalle

  • Artículo

Se aplica a: SQL Server Azure SQL Database Azure SQL Managed Instance

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 del modo por lotes

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

La característica de combinaciones adaptables del modo por lotes permite elegir un método de combinación hash o combinación de bucles anidados que se aplace hasta después de que se haya examinado la primera entrada, mediante un único plan en caché. El operador de combinaciones adaptables define un umbral que se usa para decidir cuándo cambiar a un plan de bucles anidados. El plan, por tanto, puede cambiar de forma dinámica para una mejor estrategia de combinación 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 usan los recuentos de filas reales de la función para tomar decisiones fundamentadas sobre los planes de consulta descendentes.

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 usa funciones con valores de tabla de varias instrucciones (MSTVF), la optimización se pausará, ejecutará el subárbol aplicable, capturará estimaciones de cardinalidad precisas y, a continuación, reanudará la optimización para las operaciones de bajada.

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 de filas real frente a las filas estimadas. Hay tres áreas reseñables del plan (el flujo va de derecha a izquierda):

  • El recorrido 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 las MSTVF devuelven en realidad, es probable que lo mejor sea un algoritmo de combinación totalmente 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.

Gráfico de un flujo de filas del plan de ejecución frente a filas estimadas.

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

Gráfico del plan de ejecución intercalado.

  • Observe que el recorrido de tabla de MSTVF ahora refleja una estimación de cardinalidad precisa. Observe también el reordenamiento de este examen de tabla y 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 también que ya no hay advertencias de desbordamiento, dado que se ha concedido más memoria en función del recuento real de filas que pasan desde el recorrido de tabla de MSTVF.

Instrucciones aptas de ejecución intercalada

Las instrucciones que hacen referencia a las MSTVF en la ejecución intercalada de momento deben ser de solo lectura y no formar parte de ninguna 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 donde:

  • Hay una gran distorsión entre el número real de filas y el estimado del conjunto de resultados intermedio (en este caso, las MSTVF).
  • Y la consulta global es sensible a un cambio en el tamaño del resultado intermedio. Esto suele suceder cuando hay un árbol complejo por encima de ese subárbol en el plan de consulta. Un simple instrucción SELECT * de una MSTVF no se beneficiará de la ejecución intercalada.

Sobrecarga de la ejecución intercalada

La sobrecarga debe ser de mínima a ninguna. Las MSTVF ya se estaban materializando antes de la introducción de la ejecución intercalada; la diferencia es que ahora se permite la optimización diferida y luego se utiliza la estimación de cardinalidad del conjunto de filas materializado. Al igual que cualquier plan que afecte a los cambios, algunos planes podrían cambiar de modo que con la mejor cardinalidad del subárbol se obtuviera un plan peor para la consulta en general. La mitigación puede incluir la reversión del nivel de compatibilidad o el uso del Almacén de consultas para aplicar la versión no revertida del plan.

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.

Seguimiento de la actividad de ejecución intercalada

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

Atributo del plan de ejecución Descripción
ContainsInterleavedExecutionCandidates Se aplica al nodo QueryPlan. Si true significa que el plan contiene candidatos de ejecución intercalada.
IsInterleavedExecuted Atributo del elemento RuntimeInformation bajo el elemento RelOp del nodo de 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 realizar un seguimiento de las repeticiones de ejecución intercaladas a través de los siguientes eventos extendidos:

XEvent Descripción
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 desencadena cuando una consulta con un posible candidato para la ejecución intercalada no consigue realmente la ejecución intercalada.

Se debe ejecutar una consulta para permitir que la ejecución intercalada revise las estimaciones de cardinalidad de MSTVF. Pero el plan de ejecución estimado aún muestra cuándo hay candidatos de ejecución intercalada a través del atributo del plan de presentación de ContainsInterleavedExecutionCandidates.

Almacenamiento en caché de la ejecución intercalada

Si un plan se borra o se elimina de la memoria caché, al ejecutarse la consulta se genera una nueva compilación 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 Almacén de consultas

Los planes con ejecución intercalada se pueden aplicar. 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 ámbito de base de datos o de instrucción mientras se mantiene el nivel de compatibilidad de base de datos 140 o posterior. 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], [foo].[OutlierEventQuantity]
FROM [Fact].[Order] AS [fo]
INNER JOIN [Fact].[WhatIfOutlierEventQuantity]('Mild Recession',
                            '1-01-2013',
                            '10-15-2014') AS [foo] ON [fo].[Order Key] = [foo].[Order Key]
                            AND [fo].[City Key] = [foo].[City Key]
                            AND [fo].[Customer Key] = [foo].[Customer Key]
                            AND [fo].[Stock Item Key] = [foo].[Stock Item Key]
                            AND [fo].[Order Date Key] = [foo].[Order Date Key]
                            AND [fo].[Picked Date Key] = [foo].[Picked Date Key]
                            AND [fo].[Salesperson Key] = [foo].[Salesperson Key]
                            AND [fo].[Picker Key] = [foo].[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 de UDF escalar

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 de UDF escalar facilita la optimización basada en costos 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 de recuento de filas se usará para optimizar las operaciones del plan de bajada.

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

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 en función del recuento de filas de variables de tabla de la compilación diferida. Este plan se reutiliza en consultas sucesivas, y hasta que se expulsa o se vuelve a compilar.

El recuento de filas de variables de tabla que se usa para la compilación inicial del plan representa un valor típico que podría ser diferente de una estimación del recuento de filas fijo. Si es diferente, las operaciones de bajada saldrán beneficiadas. 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 variables de tabla en el ámbito de base de datos o de instrucción mientras se mantiene el nivel 150 o posterior de compatibilidad de base de datos. 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 confidencialidad de parámetros

Se aplica a: SQL Server 2022 (16.x) Azure SQL Database Azure SQL Managed Instance

La optimización del plan de confidencialidad de parámetros (PSP) forma parte de la familia de características de procesamiento de consultas inteligentes. Aborda el escenario en el que un único plan almacenado en caché de una consulta con parámetros no es óptimo para todos los valores de parámetro entrantes posibles. 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.

Número aproximado de valores no nulos únicos

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 más información, consulte APPROX_COUNT_DISTINCT (Transact-SQL).

Percentil aproximado

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

Estas funciones de agregado calculan percentiles para un conjunto de datos grande con límites de error aceptables basados en clasificación para ayudar a tomar decisiones rápidas mediante funciones de agregado percentil aproximados.

Para obtener más información, vea APPROX_PERCENTILE_DISC (Transact-SQL) y APPROX_PERCENTILE_CONT (Transact-SQL)

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 almacén de filas permite la compatibilidad con todos operadores habilitados para el modo por lotes existentes.

Nota:

La documentación utiliza el término árbol B generalmente en referencia a los índices. En los índices del almacén de filas, el motor de la 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 de las mejoras de escalabilidad relacionadas con el proceso en modo 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:

  • Mediante el uso de índices de almacén de columnas, más datos suyos caben en la 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, es posible evaluar agregados del modo por lotes como parte de una exploración del índice de almacén de columnas. Asimismo, los datos comprimidos del almacén de columnas se procesan mediante la codificación en longitud del recorrido de forma mucho más eficiente con combinaciones y agregados de modo por lotes.

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

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

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 contexto no son compatibles con la compresión del almacén de columnas. Por tanto, los desencadenadores no se admiten en tablas con índices de almacén de columnas en clúster. Y, lo que es más importante, los índices de almacén de columnas agregan sobrecarga para 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 se pueden beneficiar del uso de CPU mejorado mediante el procesamiento de modo por lotes por sí solo. Por esa razón la característica de modo por lotes en almacén de filas considera el modo por lotes para todas las consultas, independientemente del tipo de índices implicados.

Cargas de trabajo que pueden beneficiarse del modo por lotes en el almacén de filas

Las siguientes cargas de trabajo pueden beneficiarse del modo por lotes en el almacén de filas:

  • 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 sigue recomendando tener en cuenta 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 todavía no es compatible con los índices de almacén de columnas.

Nota:

El modo por lotes en el almacén de filas solo sirve para reducir el consumo de CPU. Si el cuello de botella está relacionado con la E/S y los datos todavía no están almacenados en caché (caché "en frío"), el modo por lotes en el almacén de filas no mejorará el tiempo transcurrido de la consulta. De forma similar, si no hay memoria suficiente en el equipo para almacenar en caché todos los datos, es poco probable que mejore el rendimiento.

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

El modo por lotes en el almacén de filas requiere la base de datos en el nivel 150 de compatibilidad.

Incluso si una consulta no accede a ninguna tabla con índice de almacén de columnas, el procesador de consultas usa la heurística para decidir si se va a 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 el almacén de filas, verá el modo de ejecución real como modo por lotes en el plan de consulta. El operador de examen usa el modo por lotes para montones 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 hash, agregados basados en hash, ordenaciones, agregados de ventana, filtros, concatenación y operadores Compute Scalar.

Comentarios

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 obtiene un plan de modo por lotes, podría no ser igual al plan obtenido con un índice de almacén de columnas.

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 examen de modo por lotes en el almacén de filas:

  • no se iniciará para tablas OLTP en memoria, ni para los índices que no sean de montones en disco y árboles 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 para las que no se usa el modo por lotes incluso con índices de almacén de columnas. Entre los ejemplos se incluyen consultas que implican cursores. Estas mismas exclusiones también se amplían al modo por lotes en el almacén de filas.

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

La configuración con ámbito de base de datos de BATCH_MODE_ON_ROWSTORE 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 el almacén de filas a través de la configuración con ámbito de base de datos. Pero todavía puede invalidar la configuración en el nivel de consulta mediante la sugerencia de consulta ALLOW_BATCH_MODE. El ejemplo siguiente habilita el modo por lotes en el almacén de filas incluso con la característica deshabilitada a través de la configuración de á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 el almacén de filas para una consulta específica mediante 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'));

Características de comentarios de procesamiento de consultas

Las características de comentarios de procesamiento de consultas forman parte de la familia de características de procesamiento de consultas inteligentes.

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 ejecuta correctamente, conservamos estas modificaciones en el disco en memoria o en la 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.

Comentarios de concesión de memoria

Los comentarios de concesión de memoria se han introducido en oleadas en las últimas versiones principales de SQL Server.

Comentarios de concesión de memoria en modo por lotes

Para obtener información sobre los comentarios de concesión de memoria del modo por lotes, visite Comentarios de concesión de memoria del modo por lotes.

Comentarios de concesión de memoria del modo de fila

Para obtener información sobre los comentarios sobre la concesión de memoria del modo de fila, visite Comentarios de concesión de memoria del modo de fila.

Comentarios de concesión de memoria en modo percentil y 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 los comentarios de DOP, visite Los comentarios sobre el grado de paralelismo (DOP).

Comentarios de estimación de cardinalidad (CE)

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

Forzado de plan optimizado con Almacén de consultas

Para obtener información sobre el forzado de planes optimizados con el almacén de consultas, visite Plan optimizado forzado con el almacén de consultas.

Contenido relacionado