September 30, 2014 at 7:39 am
Hola, tengo el sgte inconveniente con una tabla de 9000 filas, la cual en teoria no es una tabla grande, cuando se realiza un SELECT de esta tabla demora mucho.
Tiene un indice PRIMARY KEY CLUSTERED de tipo entero autoincremental.
Mi duda es por que demora mucho si no es una tabla con muchos registros.
September 30, 2014 at 8:12 am
Most people on this forum speak English. If you can translate your question, you will probably get a better response.
The absence of evidence is not evidence of absence
- Martin Rees
The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
- Phil Parkin
September 30, 2014 at 8:21 am
sistemas_casinomnes (9/30/2014)
Hola, tengo el sgte inconveniente con una tabla de 9000 filas, la cual en teoria no es una tabla grande, cuando se realiza un SELECT de esta tabla demora mucho.Tiene un indice PRIMARY KEY CLUSTERED de tipo entero autoincremental.
Mi duda es por que demora mucho si no es una tabla con muchos registros.
[Rough translation from Google]
Hi, I have the drawback sgte with a table of 9000 rows, which in theory is not a large table, when a SELECT from this table takes much is done.
It has a PRIMARY KEY CLUSTERED index of auto-increment integer.
My question is why it takes a lot if there is a table with many records.
9000 rows is not a large table by any definition. In general, your query should come back very quickly. If it is slow, there are many things that could be causing it.
You would need to post DDL for the table, some test data, your query and the execution plan from your slow query to even begin to start to guess at the cause of the slowness.
__________________________________________________________________________________________________________
How to Post to get the most: http://www.sqlservercentral.com/articles/Best+Practices/61537/
September 30, 2014 at 8:22 am
Please post full table DDL, the SELECT statement that's running slowly, and the actual execution plan for the query.
John
September 30, 2014 at 8:36 am
It looks like John beat me to it, if you can post a query plan that would be a great help - see: How to Post Performance Problems[/url]
-- Itzik Ben-Gan 2001
September 30, 2014 at 8:41 am
My translation:
Hi, I have the following inconvenient with a table with 9000 rows, which in theory is not a big table. When a SELECT is run on this table is taking too long.
It has a PRIMARY KEY CLUSTERED index which is an auto-increment integer.
My question is why does it take so long if it's not a table with many rows.
(English below)
Como mencionan los demás, necesitamos más detalles ¿Cómo estás consultando la tabla? Necesitamos ver la estructura de la tabla (se pueden cambiar los nombres de los campos) y el SELECT que estás usando. Hay muchas cosas que pueden ser, desde bloqueos hasta memoria del cliente. Por favor, define a que te refieres con demasiado tiempo.
(English)
As everyone else mentioned, we need more details. How are you querying the table? We need to see the structure of the table (column names can be different to the real ones) and the SELECT statement that you're using. There are many reasons that can go from blocking to memory available in the client. Please, define what you mean when you say too long.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply