¿La forma más rápida de contar el número exacto de filas en una tabla muy grande?

La forma más rápida en MySQL es:

SHOW TABLE STATUS;

Obtendrá instantáneamente todas sus tablas con el recuento de filas (que es el total) junto con mucha información adicional si lo desea.

He encontrado artículos que indican que SELECT COUNT(*) DE TABLE_NAME será lento cuando la tabla tenga muchas filas y muchas columnas.

Eso depende de la base de datos. Algunos aceleran los recuentos, por ejemplo, haciendo un seguimiento de si las filas están activas o muertas en el índice, lo que permite un análisis de índice solo para extraer el número de filas. Otros no lo hacen, y en consecuencia requieren visitar toda la mesa y contar filas vivas una por una. Cualquiera será lento para un enorme tabla.

Tenga en cuenta que generalmente puede extraer una buena estimación mediante el uso de herramientas de optimización de consultas, estadísticas de tablas, etc. En el caso de PostgreSQL, por ejemplo, podría analizar la salida de explain count(*) from yourtable y obtener una estimación razonablemente buena del número de filas. Lo que me lleva a su segunda pregunta.

Tengo una tabla que podría contener incluso miles de millones de filas [tiene aproximadamente 15 columnas]. ¿Hay una mejor manera de obtener el recuento EXACTO del número de filas de un ¿mesa?

En serio? :- ) ¿Realmente quieres decir el exacto contar de una tabla con miles de millones de filas? ¿Estás realmente seguro? :-)

Si realmente lo hace, podría mantener un rastro del total usando disparadores, pero tenga en cuenta la concurrencia y los bloqueos si lo hace.

Puede probar esto sp_spaceused (Transact-SQL)

Muestra el número de filas, disco espacio reservado y espacio en disco utilizado por una tabla, una vista indexada o un Servicio Cola de broker en la base de datos actual, o muestra el espacio en disco reservado y utilizado por toda la base de datos.

¿Hay una mejor manera de obtener el recuento EXACTO del número de filas de una tabla?

Para responder a su pregunta simplemente, No .

Si necesita una forma independiente de DBMS para hacer esto, la forma más rápida siempre será:

SELECT COUNT(*) FROM TableName

Algunos proveedores de DBMS pueden tener formas más rápidas que funcionarán solo para sus sistemas. Algunas de estas opciones ya están publicadas en otras respuestas.

COUNT(*) debe ser optimizado por el DBMS (al menos cualquier PROD digno de DB) de todos modos, así que no trate de eludir sus optimizaciones.

En una nota al margen:
Estoy seguro de que muchas de sus otras consultas también tardan mucho tiempo en terminar debido al tamaño de su mesa. Cualquier problema de rendimiento debería abordarse pensando en el diseño de su esquema teniendo en cuenta la velocidad. Me doy cuenta de que dijo que no es una opción para cambiar, pero podría resultar que las consultas de más de 10 minutos tampoco son una opción. 3rd NF no siempre es el mejor enfoque cuando se necesita velocidad, y a veces datos puede particionarse en varias tablas si los registros no tienen para almacenarse juntos. Algo en lo que pensar...

Utilizo

select /*+ parallel(a) */  count(1) from table_name a;

No soy tan experto como otros que han respondido, pero tenía un problema con un procedimiento que estaba utilizando para seleccionar una fila aleatoria de una tabla (no demasiado relevante), pero necesitaba saber el número de filas en mi tabla de referencia para calcular el índice aleatorio. Usar el conteo tradicional(*) o Conteo(1) funciona, pero ocasionalmente obtenía hasta 2 segundos para que mi consulta se ejecutara. Así que en su lugar (para mi tabla llamada 'tbl_HighOrder') estoy usando:

Declare @max int

Select @max = Row_Count
From sys.dm_db_partition_stats
Where Object_Name(Object_Id) = 'tbl_HighOrder'

Funciona muy bien y los tiempos de consulta en Estudio de Gestión son cero.

Si la edición de SQL Server es 2005/2008, puede usar DMV para calcular el número de filas en una tabla:

-- Shows all user tables and row counts for the current database 
-- Remove is_ms_shipped = 0 check to include system objects 
-- i.index_id < 2 indicates clustered index (1) or hash table (0) 
SELECT o.name, 
 ddps.row_count 
FROM sys.indexes AS i 
 INNER JOIN sys.objects AS o ON i.OBJECT_ID = o.OBJECT_ID 
 INNER JOIN sys.dm_db_partition_stats AS ddps ON i.OBJECT_ID = ddps.OBJECT_ID 
 AND i.index_id = ddps.index_id 
WHERE i.index_id < 2 
 AND o.is_ms_shipped = 0 
ORDER BY o.NAME 

Para el motor de base de datos SQL Server 2000, los sysindexes funcionarán, pero se recomienda encarecidamente evitar su uso en futuras ediciones de SQL Server, ya que puede eliminarse en un futuro próximo.

Código de muestra tomado de: Cómo Obtener Recuentos De Filas De Tablas De Forma Rápida E Indolora

Bueno, tarde por 5 años y sin saber si ayuda :

Estaba tratando de contar el no. de filas en una tabla de SQL Server usando MS SQL Server Management Studio y se encontró con algún error de desbordamiento, luego utilicé lo siguiente:

Seleccione count_big (1) DESDE [dbname].[dbo].[FactSampleValue];

El resultado:

24296650578 filas

No creo que haya una solución general siempre más rápida: algunos RDBMS/versiones tienen una optimización específica para SELECT COUNT(*) que usan opciones más rápidas, mientras que otros simplemente escanean tablas. Usted tendría que ir a los sitios de documentación/soporte para el segundo conjunto, que probablemente necesitará alguna consulta más específica para ser escrito, por lo general uno que llega a un índice de alguna manera.

EDITAR:

Aquí hay un pensamiento que podría funcionar, dependiendo de su esquema y distribución de datos: ¿tiene un indexado columna que hace referencia a un valor creciente, un ID creciente numérico, digamos, o incluso una marca de tiempo o fecha? Luego, suponiendo que no se produzcan eliminaciones, debería ser posible almacenar el recuento hasta algún valor reciente (fecha de ayer, valor de ID más alto en algún punto de muestra reciente) y agregar el recuento más allá de eso, lo que debería resolverse muy rápidamente en el índice. Muy dependiente de valores e índices, por supuesto, pero aplicable a casi cualquier versión de cualquier DBMS.

No es exactamente una solución independiente de DBMS, pero al menos su código de cliente no verá la diferencia...

Cree otra tabla T con solo una fila y un campo entero N¹, y crear INSERT TRIGGER que solo ejecuta:

UPDATE T SET N = N + 1

También crea un DISPARADOR DELETE que ejecuta:

UPDATE T SET N = N - 1

Un DBMS digno de su sal garantizará la atomicidad de las operaciones anteriores², y N contendrá el recuento preciso de filas en todo momento, que luego es súper rápido de obtener simplemente:

SELECT N FROM T

Si bien los disparadores son específicos de DBMS, seleccionar de T no lo es y el código de cliente no tendrá que cambiar para cada DBMS compatible.

Sin embargo, esto puede tener algunos problemas de escalabilidad si la tabla es intensiva en INSERTAR o ELIMINAR, especialmente si no se confirma inmediatamente después de INSERTAR/ELIMINAR.

¹ Estos nombres son solo marcadores de posición: use algo más significativo en la producción.

² Es decir, no se puede cambiar por una transacción concurrente entre la lectura y la escritura en N, siempre y cuando tanto la lectura como la escritura se realicen en una sola instrucción SQL.

Una respuesta literalmente insana, pero si tiene algún tipo de sistema de replicación configurado (para un sistema con mil millones de filas, espero que lo haga), puede usar un estimador aproximado (como MAX(pk)), dividir ese valor por el número de esclavos que tiene, ejecutar varias consultas en paralelo.

En su mayor parte, particionarías las consultas entre esclavos en función de la mejor clave (o la clave primaria, supongo), de tal manera (vamos a usar 250000000 como nuestras Filas / Esclavos):

-- First slave
SELECT COUNT(pk) FROM t WHERE pk < 250000000
-- Ith slave where 2 <= I <= N - 1
SELECT COUNT(pk) FROM t WHERE pk >= I*250000000 and pk < (I+1)*250000000
-- Last slave
SELECT COUNT(pk) FROM t WHERE pk > (N-1)*250000000

Pero necesitas SQL solo. Qué desastre. Bien, digamos que eres un sadomasoquista. En el maestro (o esclavo más cercano) lo más probable es que necesite crear una tabla para esto:

CREATE TABLE counter_table (minpk integer, maxpk integer, cnt integer, slaveid integer)

Así que en lugar de solo tener los selects corriendo en tus esclavos, tendrías que hacer una inserción, similar a esto:

INSERT INTO counter_table VALUES (I*25000000, (I+1)*250000000, (SELECT COUNT(pk) FROM ... ), @@SLAVE_ID)

Puede tener problemas con los esclavos escribiendo en una tabla en master. Es posible que tenga que conseguir aún más sadis-Quiero decir, creativo:

-- A table per slave!
INSERT INTO counter_table_slave_I VALUES (...)

Al final debe tener un esclavo que exista último en el camino recorrido por el gráfico de replicación, relativo al primer esclavo. Ese esclavo ahora debería tener todos los demás contra-valores, y debería tener sus propios valores. Pero para cuando hayas terminado, probablemente haya filas agregadas, por lo que tendrás que insertar otra que compense el pk máximo registrado en tu counter_table y el pk máximo actual.

En ese punto, tendría que hacer una función de agregado para averiguar cuáles son las filas totales, pero eso es más fácil ya que lo estaría ejecutando como máximo el " número de esclavos que tiene y cambiar " filas.

Si estás en la situación en la que tienes tablas separadas en los esclavos, puedes UNION obtener todas las filas que necesitas.

SELECT SUM(cnt) FROM (
    SELECT * FROM counter_table_slave_1
      UNION
    SELECT * FROM counter_table_slave_2
      UNION
    ...
  )

O ya sabes, ser un poco menos loco y migrar sus datos a un sistema de procesamiento distribuido, o tal vez utilizar una solución de Almacenamiento de datos (que le dará datos impresionante crunching en el futuro también).

Tenga en cuenta que esto depende de lo bien que esté configurada su replicación. Puesto que el cuello de botella primario es probable que sea almacenamiento persistente, si tiene almacenamiento cruddy o almacenes de datos mal segregados con ruido vecino pesado, esto probablemente lo ejecutará más lento que simplemente esperar un solo SELECT COUNT(*) ...

Pero si tiene una buena replicación, entonces sus ganancias de velocidad deben estar directamente relacionadas con el número o los esclavos. De hecho, si tarda 10 minutos en ejecutar la consulta de conteo solo, y tiene 8 esclavos, reduciría su tiempo a menos de un par de minutos. Tal vez una hora para pulir los detalles de este solución.

Por supuesto, nunca obtendrías una respuesta increíblemente precisa ya que esta solución distribuida introduce un poco de tiempo donde las filas se pueden eliminar e insertar, pero puedes intentar obtener un bloqueo distribuido de filas en la misma instancia y obtener un recuento preciso de las filas en la tabla para un momento en particular.

En realidad, esto parece imposible, ya que básicamente estás atascado con una solución de solo SQL, y no creo que se le proporciona un mecanismo para ejecutar un sharded y consulta bloqueada a través de múltiples esclavos, al instante. Tal vez si tuviera el control del archivo de registro de replicación... lo que significa que literalmente estaría girando esclavos para este propósito, que es sin duda más lento que simplemente ejecutar la consulta de conteo en una sola máquina de todos modos.

Así que ahí están mis dos centavos de 2013.

Si insert trigger es demasiado caro de usar, pero se podría permitir un delete trigger, y hay un incremento automáticoid, luego, después de contar toda la mesa una vez, y recordar el conteo como last-count y el last-counted-id,

Entonces cada día sólo necesitas contar para id > last-counted-id, añadir que a last-count, y almacenar el nuevo last-counted-id.

El disparador delete disminuiría el último conteo, si el id del registro eliminado

Llego tarde a esta pregunta, pero esto es lo que puedes hacer con MySQL (ya que uso MySQL). Estoy compartiendo mis observaciones aquí:

1) SELECT COUNT(*) AS TOTAL_ROWS FROM <TABLE_NAME>

Resultado
Recuento de Filas: 508534
Salida de consola: Filas afectadas: 0 Filas encontradas: 1 Advertencias: 0 Duración de 1 consulta: 0.125 seg.
Toma un tiempo para una tabla con un gran número de filas, pero el recuento de filas es muy exacto.

2) SHOW TABLE STATUS or SHOW TABLE STATUS WHERE NAME="<TABLE_NAME>"

Resultado
Recuento de filas: 511235
Salida de consola: Filas afectadas: 0 Filas encontradas: 1 Advertencias: 0 Duración para 1 consulta: 0.250 seg Resumen: El recuento de filas no es exacto.

3) SELECT * FROM information_schema.tables WHERE table_schema = DATABASE();

Resultado
Recuento de filas: 507806
Salida de consola: Filas afectadas: 0 Filas encontradas: 48 Advertencias: 0 Duración de 1 consulta: 1.701 seg.
El recuento de filas no es exacto.

No soy un experto en MySQL o bases de datos, pero he encontrado que para tablas muy grandes, puede usar la opción 2 o 3 y obtener una 'idea justa' de cuántas filas están presentes.

Necesitaba obtener estas filas cuentan para mostrar algunas estadísticas en la interfaz de usuario. Con las consultas anteriores, sabía que las filas totales eran más de 500,000, así que se me ocurrió mostrar estadísticas como "Más de 500,000 filas" sin mostrar el número exacto de filas.

Tal vez no haya respondido realmente a la pregunta de la OP, pero estoy compartiendo lo que hice en una situación en la que se necesitaban tales estadísticas. En mi caso, mostrar las filas aproximadas era aceptable y por lo que lo anterior funcionó para mí.

Si tiene una estructura de tabla típica con una columna de clave primaria de incremento automático en la que las filas nunca se eliminan, la siguiente será la forma más rápida de determinar el recuento de registros y debería funcionar de manera similar en la mayoría de las bases de datos compatibles con ANSI:

SELECT TOP(1) <primarykeyfield> FROM <table> ORDER BY <primarykeyfield> DESC;

Trabajo con tablas de MS SQL que contienen miles de millones de filas que requieren tiempos de respuesta de menos de un segundo para los datos, incluidos los recuentos de registros. Un RECUENTO DE SELECCIÓN similar(*) tardaría minutos en procesarse por comparación.

Encontré este buen artículo SQL Server–HOW-TO: recupere rápidamente el recuento de filas preciso para la tabla de martijnh1 que da un buen resumen para cada escenario.

Necesito que esto se amplíe donde necesito proporcionar un recuento basado en una condición específica y cuando calcule esta parte, actualizaré esta respuesta aún más.

Mientras tanto, aquí están los detalles del artículo:

Método 1:

Consulta:

SELECT COUNT(*) FROM Transactions 

Observaciones:

Realiza un análisis completo de la tabla. Lento en mesas grandes.

Método 2:

Consulta:

SELECT CONVERT(bigint, rows) 
FROM sysindexes 
WHERE id = OBJECT_ID('Transactions') 
AND indid < 2 

Comentarios:

Forma rápida de recuperar el recuento de filas. Depende de las estadísticas y es inexacta.

Ejecute DBCC UPDATEUSAGE(Base de datos) CON COUNT_ROWS, que puede tomar un tiempo significativo para tablas grandes.

Método 3:

Consulta:

SELECT CAST(p.rows AS float) 
FROM sys.tables AS tbl 
INNER JOIN sys.indexes AS idx ON idx.object_id = tbl.object_id and
idx.index_id < 2 
INNER JOIN sys.partitions AS p ON p.object_id=CAST(tbl.object_id AS int) 
AND p.index_id=idx.index_id 
WHERE ((tbl.name=N'Transactions' 
AND SCHEMA_NAME(tbl.schema_id)='dbo')) 

Comentarios:

La forma en que el SQL management studio cuenta filas (consulte propiedades de tabla, almacenamiento, recuento de filas). Muy rápido, pero todavía un número aproximado de filas.

Método 4:

Consulta:

SELECT SUM (row_count) 
FROM sys.dm_db_partition_stats 
WHERE object_id=OBJECT_ID('Transactions')    
AND (index_id=0 or index_id=1); 

Comentarios:

Operación rápida (aunque no tan rápida como el método 2) e igualmente importante, confiable.

Seleccionar filas desde sysindexes donde id = Object_ID ('TableName') e indid

Ponga un índice en alguna columna. Esto debería permitir al optimizador realizar un análisis completo de los bloques de índice, en lugar de un análisis completo de la tabla. Eso reducirá sus costos de E / s. Mira el plan de ejecución antes y después. Luego mida el tiempo del reloj de pared en ambos sentidos.

Si está utilizando Oracle, qué tal esto (suponiendo que las estadísticas de la tabla se actualizan):

select <TABLE_NAME>, num_rows, last_analyzed from user_tables

Last_analyzed mostrará la hora en que se recopilaron las estadísticas por última vez.

Para Sql server pruebe esto

SELECT T.name, 
       I.rows AS [ROWCOUNT] 
FROM   sys.tables AS T 
       INNER JOIN sys.sysindexes AS I 
               ON T.object_id = I.id AND I.indid < 2 
WHERE T.name = 'Your_Table_Name'
ORDER  BY I.rows DESC 

Obtuve este script de otra pregunta/respuesta de StackOverflow:

SELECT SUM(p.rows) FROM sys.partitions AS p
  INNER JOIN sys.tables AS t
  ON p.[object_id] = t.[object_id]
  INNER JOIN sys.schemas AS s
  ON s.[schema_id] = t.[schema_id]
  WHERE t.name = N'YourTableNameHere'
  AND s.name = N'dbo'
  AND p.index_id IN (0,1);

Mi tabla tiene 500 millones de registros y lo anterior devuelve en menos de 1 ms. Mientras tanto,

SELECT COUNT(id) FROM MyTable

Toma 39 minutos, 52 segundos!

Producen exactamente el mismo número de filas (en mi caso, exactamente 519326012).

No sé si ese sería siempre el caso.

Con PostgreSQL:

SELECT reltuples AS approximate_row_count FROM pg_class WHERE relname = 'table_name'

Si tiene una clave primaria (valor único) en algún lugar de su tabla, puede usar MAX(yourId) para darle esencialmente el recuento de filas totales. A continuación se muestra un fragmento de muestra:

SELECT MAX(yourId)
FROM YourTable

Tal vez un poco tarde, pero esto podría ayudar a otros para MSSQL

; CON RecordCount AS (SELECT ROW_NUMBER () OVER (ORDER BY COLUMN_NAME) AS [RowNumber] FROM TABLE_NAME) SELECT MAX (Número de fila) DE RecordCount