ESTABLECER NOCOUNT EN el uso

Me llevó mucho investigar para encontrar cifras reales de referencia alrededor de NOCOUNT, así que pensé en compartir un breve resumen.

• Si su procedimiento almacenado utiliza un cursor para realizar muchas operaciones muy rápidas sin resultados devueltos, tener NOCOUNT APAGADO puede tomar aproximadamente 10 veces más que tenerlo ACTIVADO. ¹ Este es el peor de los casos.
• Si su procedimiento almacenado solo realiza una sola operación rápida sin resultados devueltos, al establecer NOCOUNT ON se rendimiento alrededor de un aumento de rendimiento del 3%. ² Esto sería coherente con un procedimiento típico de inserción o actualización.
• Si su procedimiento almacenado devuelve resultados (es decir, selecciona algo), la diferencia de rendimiento disminuirá proporcionalmente con el tamaño del conjunto de resultados.

• Cuando SET NOCOUNT está ACTIVADO, no se devuelve el recuento (que indica el número de filas afectadas por una instrucción Transact-SQL). Cuando SET NOCOUNT está DESACTIVADO, se devuelve el recuento. Se utiliza con cualquier instrucción SELECT, INSERT, UPDATE, DELETE.

• La configuración de SET NOCOUNT se establece en tiempo de ejecución o ejecución y no en tiempo de análisis.

• ESTABLECER NOCOUNT ON mejora el rendimiento del procedimiento almacenado (SP).

• Sintaxis: SET NOCOUNT { ON / OFF }

Ejemplo de SET NOCOUNT ON:

Ejemplo de SET NOCOUNT OFF:

Supongo que hasta cierto punto es un problema de DBA vs.desarrollador.

Como desarrollador en su mayoría, diría que no lo use a menos que sea absolutamente necesario, porque usarlo puede romper su ADO.NET código (según lo documentado por Microsoft).

Y supongo que como DBA, estaría más en el otro lado: úselo siempre que sea posible a menos que realmente deba evitar su uso.

También, si sus desarrolladores alguna vez usan los "RecordsAffected" que devuelven ADO.NET 's ExecuteNonQuery método de llamada, usted está en problemas si todo el mundo usa SET NOCOUNT ON ya que en este caso, ExecuteNonQuery siempre devolverá 0.

También ver la entrada del blog de Peter Bromberg y echa un vistazo a su posición.

Así que todo se reduce a quién establece los estándares: -)

Marc

Si estás diciendo que también podrías tener diferentes clientes, hay problemas con classic ADO si SET NOCOUNT no está ACTIVADO.

Uno que experimento regularmente: si un procedimiento almacenado ejecuta un número de instrucciones (y por lo tanto se devuelven un número de mensajes "xxx filas afectadas"), ADO parece no manejar esto y lanza el error "No se puede cambiar la propiedad ActiveConnection de un objeto Recordset que tiene un objeto Command como su fuente."

Así que generalmente abogo activarlo a menos que haya una realmente realmente buena razón para no hacerlo. es posible que haya encontrado la muy, muy buena razón por la que necesito ir y leer más.

A riesgo de complicar las cosas, recomiendo una regla ligeramente diferente a todas las que veo arriba:

• Siempre establezca NOCOUNT ON en la parte superior de un proc, antes de hacer cualquier trabajo en el proc, pero también siempre SET NOCOUNT OFF de nuevo, antes de devolver cualquier conjunto de registros del proc almacenado.

Así que "por lo general no se debe contar, excepto cuando realmente se está devolviendo un conjunto de resultados". No conozco ninguna manera de que esto pueda romper cualquier código de cliente, significa que el código de cliente nunca necesita saber algo sobre los internos del proc, y no es particularmente oneroso.

Con respecto a los desencadenantes que rompen NHibernate, tuve esa experiencia de primera mano. Básicamente, cuando NH hace una ACTUALIZACIÓN espera cierto número de filas afectadas. Al agregar SET NOCOUNT a los disparadores, obtiene el número de filas de nuevo a lo que NH esperaba, solucionando así el problema. Así que sí, definitivamente recomendaría apagarlo para los disparadores si usas NH.

Con respecto al uso en SPs, es una cuestión de preferencia personal. Siempre había apagado el conteo de filas, pero de nuevo, no hay argumentos fuertes de ninguna manera.

En una nota diferente, realmente debería considerar alejarse de la arquitectura basada en SP, entonces ni siquiera tendrá esta pregunta.

ESTABLECER NOCOUNT ON; El código anterior detendrá el mensaje generado por sql server engine en la ventana de resultados fronted después de la ejecución del comando DML / DDL.

¿por Qué lo hacemos? Como SQL server engine toma algún recurso para obtener el estado y generar el mensaje, se considera una sobrecarga para Sql server engine.So activamos el mensaje sin contar.

No se como probar SET NOCOUNT ON entre cliente y SQL, así que probé un comportamiento similar para otro comando SET "SET TRANSACTION ISOLATION LEVEL READ UNIMMITTED"

Envié un comando desde mi conexión cambiando el comportamiento predeterminado de SQL (READ COMMITTED), y se cambió para los siguientes comandos. Cuando cambié el nivel de AISLAMIENTO dentro de un procedimiento almacenado, no cambió el comportamiento de conexión para el siguiente comando.

Actual conclusión,

1. Cambiar la configuración dentro del procedimiento almacenado no cambia la configuración predeterminada de la conexión.
2. Cambiar la configuración enviando comandos usando ADOConnection cambia el comportamiento predeterminado.

Creo que esto es relevante para otro comando SET como "SET NOCOUNT ON"

SET NOCOUNT ON;

Esta línea de código se utiliza en SQL para no devolver las filas numéricas afectadas en la ejecución de la consulta. Si no requerimos el número de filas afectadas, podemos usar esto ya que esto ayudaría a ahorrar uso de memoria y aumentar la velocidad de ejecución de la consulta.

If (set no count== off)

{ a continuación, mantendrá los datos de cuántos registros afectados así que reduce el rendimiento } else { no rastreará el registro de cambios por lo tanto mejorar el rendimiento } }

Sé que es una pregunta muy vieja. pero solo para actualizar.

La mejor manera de usar "SET NOCOUNT ON" es colocarlo como primera instrucción en su SP y activarlo de nuevo justo antes de la última instrucción SELECT.