Viewers: in countries Watching now:
In SQL Server 2008 Essential Training, Simon Allardice explores all the major features of SQL Server 2008 R2, beginning with core concepts: installing, planning, and building a first database. Explore how Transact-SQL is used to retrieve, update, and insert information, and gain insight into how to effectively administer databases. The course also covers features outside SQL Server's database engine, including technologies that have grown up around it: SQL Server Reporting Services and Integration Services. Exercise files are included with the course.
Flip to the back of any thick technical book and you're going to find an index. If you need to look up some content that's buried somewhere in a thousand pages of text, you're going to turn to the back of the book, scan through the index to find what you're looking for, say deviation analysis, realize it's on page 322 and then turn directly to that section to read that content. Indexes give you a quick way to look something up. That's what they do in books and that's what they do in databases. When we're working with SQL Server 2008, we can create two kinds of index.
The first is what's called a clustered index. A clustered index is applied to one of the columns in our table and it will order our table based on that index. In this case I'm looking at it as the CustomerID in ascending order. If for example I remove the clustered index from that column and applied it to the LastName column, it would require that the data itself be reorganized internally based on that clustered index. So this method of indexing will actually have an effect on the internal structure of your tables.
It'll order it internally based on the index. Now because of that, you can only ever have one clustered index per table. We can't actually order our data by both last name and customer ID at the same time. Now because of this, it is actually quite common that it's your primary key and in fact when you apply a primary key to a new table it will cluster that by default. And it's a pretty good idea to have your primary key be the clustered index. You'll be using that key to directly access those rows.
It's a very fast way to work with your content. So in this example that I'm looking at, I almost certainly wouldn't create the clustered index on the last name. I'd leave it on the CustomerID. And in that situation we might be in a place where we would use two kinds of indexes. We go back to the idea that our CustomerID was our clustered index, but we know that we also want to directly look up people by say last name or company name. It's all really dependent on what the needs of your business are. So we'll create a non-clustered index, and we'll do that on the LastName column.
What we'll do is scan through the LastName column and create its own index, a separate index that points to the different places in our table. So if we now have a non-clustered index based on LastName, and we're looking for the last name of Beck, I can scan quickly through that index. Find the entry that will actually point me to the row 16. And if you are writing SELECT statements that need to select again say in this case last name or company name, you'd want to think long and hard about do I need a non-clustered index? Because that will improve the performance of the selects of queries, of joins, with all my retrieval statements.
Non-clustered indexes than are a separate index based on a column. You can actually add multiple, so you can have several non-clustered indexes per table. Now you might be thinking well, why I don't just make everything a non-clustered index, why don't I index every single part of every single table of my database? Well here is the issue. Because you're storing that in separate indexes, if you insert a new row into that table it's going to cause an extra right per index. If you have 10 indexes and insert one row, it's going to have to update those indexes 10 times.
So, well it can improve the performance of your SELECT statements. It can certainly have a detrimental effect to your INSERTs, to your UPDATEs, to your DELETEs. We want to use non-clustered indexes when we know that we're going to be searching on that column, using that column to look something up, using it in a where clause or in ordered by, because it will help to those queries. So how do we make one? It's actually very simple. We drill down into our database and find the table that we're looking for.
Let's say for example we're working with the Customer table here. Now I'm working with a very small database that only has 847 rows. But let's say I was working with one with 100,000, 200,000, two million rows. I'm going to leave the CustomerID as the clustered index, because it's a great one to have, we use the CustomerID a lot. But I might want to ask how we can improve the performance of SELECT statements that go against the LastName.
Oh, here is how I do it. I'm going to right-click Customer and jump into Design. Well it doesn't become immediately apparent, the best way to look at your indexes is right click in the blank area here and select the Indexes/Keys section. And one that is actually telling me is that I have a couple of indexes already there. I've got the PK_Customer_customerID, PK representing not surprisingly primary key. So our primary key index is on CustomerID ascending and I can see down here it's created as clustered.
And that would have been the case when this table was first defined. There's also an extra index here on EmailAddress, so I've got the IX, which tends to represent index. It is non-clustered. Again it can't be. We can't change this to clustered, because we've already got a clustered index. But somebody has obviously indexed EmailAddress if they think they're going to use that, which is a pretty good idea. And an EmailAddress is a very good exact match. Well, I'm going to add one for the LastName. Click Add and we get IX_Customer something.
What we need to do first of is say what column that we want the index to be on. I'll click the ellipsis. It's not going to be CustomerID. It's going to be a LastName and Ascending is fine. Click OK. Doesn't have to be unique. That's fine. We would expect that in a larger or even a small company we would have multiple last names, and the type is an index. We can't just say to unique key. Nope, that's not what we're after. It's just index. So give it a name by standard. It's the table name and the field name, so I'll just call this IX_Customer_LastName.
And that's pretty much it. Close. This is still considered an unsaved change to this table. So I'm going to save this now, and we now have a non-clustered index added to our Customer table.
Find answers to the most frequently asked questions about SQL Server 2008 Essential Training .
Here are the FAQs that matched your search "" :
Sorry, there are no matches for your search "" —to search again, type in another word or phrase and click search.
Access exercise files from a button right under the course name.
Search within course videos and transcripts, and jump right to the results.
Remove icons showing you already watched videos if you want to start over.
Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.
Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.