para - ¿COUNT(*) en SQL Server es una operación de tiempo constante? ¿Si no, porque no?

set nocount on sql server para que sirve

Question

Estaba leyendo esta discusión en otra publicación donde otra persona planteó esta pregunta. Antes de leer la discusión, siempre pensé que SQL Server (y otros DBMS) mantienen un conteo global de filas para cada tabla en algún lugar de los metadatos, pero la discusión parece decir que no es así. ¿Por qué? Count(*) (sin ningún tipo de filtrado) siendo una operación tan común obtendría un gran impulso si es O (1). Incluso sin considerar COUNT(*) , el número total de filas en una tabla es una información tan fundamental. ¿Por qué no mantienen una nota?

Además, ¿por qué tenemos que "cargar" filas enteras (como se indica en la publicación que he vinculado) solo para contarlas? ¿No deberían ser suficientes índices o PK, etc. para contarlos?

Answer 1

¿Por qué tenemos que "cargar" filas enteras?

Nosotros no. SQL Server tenderá a usar el índice más pequeño que pueda usar que pueda satisfacer la consulta.

Count(*) (sin ningún tipo de filtrado) es una operación tan común

Creo que sobreestimas su prevalencia. No recuerdo la última vez que me importó el número total de filas en una sola tabla en comparación con una vista más filtrada o un recuento en una operación unida más compleja.

Sería una optimización excepcionalmente limitada que solo podría beneficiar un único estilo de consulta, y como digo, creo que ha sobreestimado la frecuencia con la que ocurre.

Answer 2

No, COUNT(*) no es una operación de tiempo constante. Un COUNT(*) debe devolver un recuento de filas que se ajusten al predicado de exploración actual (es decir, la cláusula WHERE ), por lo que solo haría que el retorno de una propiedad de metadatos no sea válido. Pero incluso si no tiene predicados, el COUNT todavía tiene que satisfacer la semántica de aislamiento de transacción actual, es decir. devuelve el recuento de filas visibles (por ejemplo, comprometidas). Así que COUNT debe, y lo hará, en SQL Server, realmente escanear y contar las filas. Algunos sistemas permiten el recuento de estimados más rápidos .

Además, como comentario lateral, depender de rows en docs.microsoft.com/en-us/sql/relational-databases/… no es confiable. Después de todo, si este conteo se garantizara de forma precisa, entonces no necesitaríamos DBCC UPDATEUSAGE(...) WITH COUNT_ROWS . Hay varios escenarios que históricamente harían que este contador se desvíe de la realidad (en su mayoría, reversiones de inserción mínimamente registradas), todo lo que sé está solucionado, pero eso aún deja los problemas de 1) tablas actualizadas de versiones anteriores que tenían los errores y 2 ) otros, aún no descubiertos, errores.

Además, ¿por qué tenemos que "cargar" filas enteras (como se indica en la publicación que he vinculado) solo para contarlas? ¿No deberían ser suficientes índices o PK, etc. para contarlos?

Esto no es 100% cierto. Hay al menos 2 escenarios que no ''cargan filas completas'':

• los índices de almacén de filas estrechos cargan solo la fila ''índice'', que puede ser mucho más pequeña
• datos del almacén de columnas carga solo los segmentos de columnas relevantes

Y la mayoría de lo que digo arriba no se aplica a las tablas de Hekaton.