摘要: 今天在sqlservercentral上看到一個帖子，關于對set statistics time on輸出兩個cpu執(zhí)行時間的解釋（大牛的解釋）：CPU time is how much time was spent by the CPU (or CPUs). Total time is how long it took from start to finish.For example, if... 閱讀全文

摘要: 前天給朋友調優(yōu)，上的生產庫用ssms遠程連接測試，5個表的連接，每個表大小都在10萬多的數據量，有幾個是hash連接，比較費時，后來調優(yōu)了幾個索引后IO明顯下降，但是在執(zhí)行時間上一直沒有明顯下降，實在是沒轍了，調優(yōu)到晚上一點鐘，睡覺，第二天繼續(xù)，最后懷疑是因為網絡問題，讓朋友上的遠程桌面生產庫直接執(zhí)行，一秒以內！暈死了，原來是因為網絡傳輸問題導致在我機器上的執(zhí)行時間延長！不過幾個表的連接比較難控制... 閱讀全文

摘要: 迄今為止，我認為最詳細的臨時表和表變量的對比。 閱讀全文

摘要: SQL優(yōu)化--使用 EXISTS 代替 IN 和 關聯(lián)查詢（inner join) 昨天的這篇文章提及到的一些問題，在這里我做一下自己的測試，測試結果以微軟標準Adventureworks數據庫內數據結構為準。 閱讀全文

摘要: http://www.mssqltips.com/tip.asp?tip=1467?
大家可以看看這篇文章，講到的是如何給一個現有表更快速的添加一個自增字段 閱讀全文

摘要: 在上一個sql大牛提出的小測試中，優(yōu)化的就是如何改變查詢，來選擇合適的連接方式。?
mssql的連接方式有三種：?
hash join?
merge join?
loop join?
在這里，對比一下三種sql server連接方式如何選擇。 閱讀全文

摘要: 大家如果對SQL優(yōu)化感興趣的話,可以進來看看，挑戰(zhàn)挑戰(zhàn)。 閱讀全文

摘要: 有朋友說兩者之間存在很大的性能差異，是由于數據庫的日志模式不一樣，simple和完整的會導致差異。?
simple的select * into 不記日志。我自己也就來做了個測試。 閱讀全文

摘要: 今天調優(yōu)某電信的大型數據庫，是一個日志型的表，其中有個自增列字段和時間（時間是每個小時小時來的，每個小時有大概23萬條記錄），以及點擊次數等日志信息，數據量在4000萬以上，sp_spaceused使用了大概2G多的磁盤空間。整個表沒有分區(qū)。整個表都是插入查詢，沒有更新操作。?
閱讀全文