奈米(nanometer)科技最有趣的一點在於當物質的粒子小到一定程度時,物質的特性會迥異於原本巨觀尺度下的物理、化學及生物特性。以無人不愛的黃金為例,當它被製成金奈米粒子(nanoparticle)時,顏色不再是金黃色而呈紅色,說明了光學性質因尺度的不同而有所變化。又如石墨因質地柔軟而被用來製作鉛筆筆芯,但同樣由碳元素構成、結構相似的碳奈米管,強度竟然遠高於不銹鋼,又具有良好的彈性,因此成為顯微探針及微電極的絕佳材料。
from http://nano.nchc.org.tw/aboutnano.php

同樣的,當資料庫大到一定程度時,許多操作特性也變得與一般"常識"完全不同,這讓平時用慣小資料庫的我大吃一驚。

最近建置了一個財務歷史資料的大型資料庫,資料來源是數萬個XML,壓縮成ZIP的大小超過1G,光解壓縮就要花上15分鐘,匯入資料庫則要花上4小時(其中有1.5個小時是在建Index),最後搞出一個超過11G的超大資料庫。

好奇想看一下總共有幾筆資料,小學生也知道用SELECT COUNT(*)查一下立見分曉,卻沒想到這個小小的查詢竟花了我十分鐘,只為了看一個數字---216,956,574(2.1億筆耶~~~ 樂透彩一期也沒這麼多注吧?)。幸好是在開發環境,若是在正式環境,這番惡搞肯定會拖垮SQL的效能,輕則挨頓臭罵,若是影響到一分鐘幾十萬上下的營運系統,搞不好連飯碗都要丟了。

嚴肅的結論是: 在正式環境中,不要隨便褻玩這種超大型的資料庫。但一個好玩的議題是,資料存在SQL Server中,SQL豈有不知Table資料筆數的道理,應該有其他更有效率的方法查資料筆數吧? 憶起當年追隨SQL大師Ryan時,他曾露了一手由PK筆數查總筆數的方法,查詢語法如下:

SELECT
dbo.sysobjects.name as 'Object Name',

dbo.sysindexes.rowcnt as 'Row Count',

dbo.sysindexes.name as 'Index Name'

FROM dbo.sysobjects INNER JOIN dbo.sysindexes

ON dbo.sysobjects.id = dbo.sysindexes.id

and dbo.sysobjects.name='financial_values' --Change the Table name here

and dbo.sysindexes.indid=1 --(1:for clustered index, 0:for non-clustered index)

實測結果,由PK Index筆數去查總筆數,零秒就有答案,這算是加速了無限大倍嗎? XD


Comments

# by steve

大師 divided by zero 會有error喔.....:P 我曾經幹過類似的事 用QueryAnalyzer給他連續select count(*) 10次 那還是只有1千萬筆 結果居然總共出現了3種結果 那是測試環境,應該是沒有人在用 大師有沒有興趣實驗看看?

# by platstar

有一點不明白,為什麼不是用 select count(PK) from financial_values 效率也是差很多

# by Jeffrey

我認為select count(PK) 跟 select(*) 的速度差別不大。理由是SQL只算筆數,並不涉及處理欄位內容,而且還有一點是PK是由五個欄位組成的,所以沒得select count(PK)。 不過我自己也好奇,還是用select count(col1)只選單一欄位跟select count(*)再比一次,結果是6'50" vs 6'50",完全相同。至於比上次10'06"快,我認為可能是對HD做過Defragment的關係。

# by tai

那請問如果要搜尋符合的條件的資料筆數有無比較快的方法

# by Jeffrey

有WHERE條件時,除了請SQL直的去逐一比對外,應該沒有什麼捷徑可抄。不過,經驗證明,當Table很大時,加對Index,Query速度有可能差上數百倍。 我的建議是,下WHERE條件時儘可能配合現有的Index,或是反過來建立一些Index配合常用的複雜Query,應該是改善查詢速度的有效途徑。

# by tai

其實該做的 Index 都作了 速度還是快不起來 20 幾萬筆 看來如果硬體升級後還是如此 那要考慮適度反正規化了...

Post a comment


80 - 68 =