When deciding on whether to create a clustered or non-clustered index, it is often helpful to know what the estimated size of the clustered index will be. Sometimes, the size of a clustered index on a particular column or columns may be very large, leading to database size bloat and increased disk I/O.
Clustered index values often repeat many times in a table's non-clustered storage structures, and a large clustered index value can unnecessarily increase the physical size of a non-clustered index. This increases disk I/O and reduces performance when non-clustered indexes are accessed.
Because of this, ideally a clustered index should be based on a single column (not multiple columns) that is as narrow as possible. This not only reduces the clustered index's physical size, it also reduces the physical size of non-clustered indexes and boosts SQL Servers overall performance.
When you create a clustered index, try to create it as a UNIQUE clustered index, not a non-unique clustered index. The reason for this is that while SQL Server will allow you to create a non-unique clustered index, under the surface, SQL Server will make it unique for you by adding a 4-byte "uniqueifer" to the index key to guarantee uniqueness. This only serves to increase the size of the key, which increases disk I/O, which reduces performance. If you specify that your clustered index is UNIQUE when it is created, you will prevent this unnecessary overhead.
Happy query....











The world seems not the same
I'm looking for a book... something that can help me deal with what might be an awkward situation. Something funny might be nice, but not necessarily big, 'ha, ha, ha,' 'laugh, laugh, laugh' funny, and certainly not make-fun-of-other-people funny but rather something human-funny. 

Gilaaa.... ngantuk pisaaaannnn...








hari ini agak ngantuk.. kurang tidur gara-gara liat hujan meteor
Lay beside me, tell me what they've done



