April 29, 2010 at 8:58 am
BTW Mr Fritchey, I get your book two days ago, is really good.
I will reorganize all indexes ( last time I did a rebuild ) and upodate the stats to see if that helps
April 29, 2010 at 9:02 am
ricardo_chicas (4/29/2010)
Yes I use sp_updatestats, The query is actually the same I am running ( just with different names)--something weird us that if I add one more number to the like contition it turns into a seek.....Btw, about the <> '0' condition, if I convert that into a abs(column) > 0 the performance improves greatly, is ok to do that, right?
You might need to do an UPDATE STATISTICS tablename WITH FULLSCAN... I'm not sure, but I'd try it.
Yes, you add one more value and now the data is selective enough that you get a seek instead of a scan. I'm pretty sure it's either your statistics, less likely, or the selectivity of the index, more likely. A varchar might not be the best thing to use for a clustering key on a table this large.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
April 29, 2010 at 9:22 am
ricardo_chicas (4/29/2010)
How many rows are in the table ?A\ 70 million rows
How many rows does the query above really return ?
A\query returns about 70 thousand
What do your indexes look like ?
CONSTRAINT [column_key:PrimaryKey] PRIMARY KEY CLUSTERED
(
[FB_ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [Tables1]
) ON [Tables1]
Thanks
This index is on the FB_ID column - not the column_key column.
The posted query plan indicates that it is scanning the non-clustered index [table1:ShipId] to satisfy the query.
Do you really have an index on column_key ?
If you have no index on column_key it is not very surprising that an index scan is used.
/SG
April 29, 2010 at 9:33 am
I think it would be a good idea to post the actual definition of Table1 including all its indexes.
Please do not edit the generated script in any way, just post what SSMS generates.
April 29, 2010 at 10:56 am
I just did the Update statistics and retrieve the ten million rows is two minutes, so I am happy now
Thanks to all of you
April 29, 2010 at 11:03 am
ricardo_chicas (4/29/2010)
I just did the Update statistics and retrieve the ten million rows is two minutes, so I am happy nowThanks to all of you
Ah, so the FULL SCAN did the trick? Good to know.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
April 29, 2010 at 11:25 am
Grant Fritchey (4/29/2010)
ricardo_chicas (4/29/2010)
I just did the Update statistics and retrieve the ten million rows is two minutes, so I am happy nowThanks to all of you
Ah, so the FULL SCAN did the trick? Good to know.
Yes, it's very nice to get this feedback. Two minutes to retrieve all that data seems reasonable.
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
April 29, 2010 at 11:54 pm
Place a job to update statistics nightly (if you dont have) so that you wont get this kind of problem next time
-------Bhuvnesh----------
I work only to learn Sql Server...though my company pays me for getting their stuff done;-)
Viewing 8 posts - 16 through 22 (of 22 total)
You must be logged in to reply to this topic. Login to reply