jaja Tenes razon, la cabeza dice una cosa y los dedos otra :S , es como bien vos decis el * considera los nulls y el otro no.
Es verdad que es casi despreciable pero la realidad es que son distintos :) y uno es mas performante que otro. De todas maneras no se puede decir que esto sea un cuello de botella ni mucho menos, lo que deberia diferenciar entre un metodo y el otro es si queremos o no considerar los nulos pero a nivel performance performance son casi lo mismo El 16/08/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> escribió: > Perdón maxi: decis: "Como comentario, es muy pero muy mala idea usar > Count(*) pero no > porque sea mas lento sino porque no te retorna los nulos y esto te > puede traer serios problemas." > > Yo hago count( campo ) y No me cuenta los nulos > En cambio > count(*) si me los cuenta > > Es decir count(campo) es como si hiciera > count(*) where campo is not null > > A eso te referís con "no te retorna los nulos" ? > > En cuanto a la difrencia de tiempos, lo probé sobre 40millones de registros, > y la diferencia es de unos cientos microsegundos. Creo que es bastante > despreciable para la mayoría de los casos. > > > -----Original Message----- > From: "Maxi Accotto" <[EMAIL PROTECTED]> > To: "Daniel Aisenberg" <[EMAIL PROTECTED]> > Date: Thu, 16 Aug 2007 15:42:20 -0300 > Subject: [dbms] count(*) vs. count(1) > > > Hola Diego! como me hacen laburar ustedes che ;-) > Lo mejor en estos casos es probar, pero para poder ver resultados > necesitamos un numerito de registros ;), aca te muestro lo que testie > y es justamente lo contrario a lo que tu amigo indica (luego explico > la logica) > > Vayamos al codigo: > > USE NORTHWIND > GO > > CREATE TABLE TEST (ID INT, FECHA DATETIME) > GO > > DECLARE @N INT > SET @N = 1 > > WHILE @N < 1000000 > BEGIN > INSERT INTO TEST VALUES (@N,DATEADD(SS,@N,GETDATE())) > SET @N = @N+1 > END > go > > > > En primer instancia creamos una tablita y le insertamos 1M de > registros, es un numero que por lo menos nos permitira ver algo :) > > Luego que tenemos esto prendemos estos 2 contadores > > SET STATISTICS IO ON > SET STATISTICS TIME ON > > y por ultimo ejecutamos las querys > > SELECT COUNT(*) FROM TEST > select COUNT(id) FROM TEST > > Ahora veamos los resultados :) > > SQL Server parse and compile time: > CPU time = 0 ms, elapsed time = 0 ms. > > (1 row(s) affected) > > Table 'TEST'. Scan count 1, logical reads 2725, physical reads 0, > read-ahead reads 0. > > SQL Server Execution Times: > CPU time = 120 ms, elapsed time = 120 ms. > > (1 row(s) affected) > > Table 'TEST'. Scan count 1, logical reads 2725, physical reads 0, > read-ahead reads 0. > > SQL Server Execution Times: > CPU time = 281 ms, elapsed time = 289 ms. > > > Como se puede observar en lo que es lecturas de IO estamos parejos :) > el tema esta mal en lo que es tiempos de procesador, la segunda > consulta demoro mucho mas que la primera. > Porque sucede esto, el Count(*) no incluye los valores nulos y el > count(id) si los incluye, esto requiere un sobreproceso. :) > > Como comentario, es muy pero muy mala idea usar Count(*) pero no > porque sea mas lento sino porque no te retorna los nulos y esto te > puede traer serios problemas. > > Abrazo > > > ----------------------------------------------------------- > Microsoft MVP en SQL Server > Mentor asociado en SQLTotalConsulting > (excelencia en servicios y consultoria SQLServer) > Orador Culminis - Microsoft Influencier > www.sqltotalconsulting.com > ----------------------------------------------------------- > > > El 16/08/07, Diego Jancic <[EMAIL PROTECTED]> escribió: > > Hola gente!, > > > > Pregunta detallista: Tengo un conocido que me dice que el count(1) es > > mas eficiente que el count(*), pero por otro lado no conozco a nadie > > que lo utilize (incluso NHibernate usa el * cuando lo tiene que > > hacer..)... ustedes que dicen?? > > > > Gracias, > > Diego > > > > > > > -- > -- ----------------------------------------------------------- Microsoft MVP en SQL Server Mentor asociado en SQLTotalConsulting (excelencia en servicios y consultoria SQLServer) Orador Culminis - Microsoft Influencier www.sqltotalconsulting.com -----------------------------------------------------------
