MySQL 效率問題

有個 table, 一個 field A 是 smallint, 用黎做 index, 另一個 field B 是 varchar(32), 會是 md5
有冇人知以下邊種效率會好 d

我這裡假設如果md5 match, 可忽略 A
  1. Case 1: SELECT * FROM table WHERE B={md5string}
複製代碼
  1. Case 2: SELECT * FROM table WHERE A='12345' AND B={md5string}
複製代碼
  1. Case 3: SELECT * FROM (SELECT * FROM table WHERE A='12345') as temp_table WHERE B={md5string}
複製代碼
假設預計會有數百萬或千萬row, 我怕 case 1 會太慢, 所以設定左 A field 做 index, 諗住行 case 3
但後來諗一般 program run if(condition1 && condition2) 時, 如 condition1 成立時才會 check condition2, 所以諗緊如果直接行 case 2 的話, 會不會也是先對 condition 1 再對 condition 2, 從而做到比 case 3 更快?

你既個smallint index同md5係特登做來提升performance定係資料本身?

本身database既 index已經係hash,你點自己做都唔會快得過database本身

最基本做法係你要where既field 加index,再EXPLAIN 睇下execution plan
只要有用到index唔係full table scan通常都好快.

真係多record到超慢你要諗既係仲用唔用MySQL

TOP

你既個smallint index同md5係特登做來提升performance定係資料本身?

本身database既 index已經係hash,你點 ...
YuiNarusawa 發表於 2015-12-24 21:46



個 md5 係源資料 ge md5
個 smallint 都係源資料演變出黎, 諗住變黎 set index 先 query 出 temp table 縮窄範圍先再對個 md5

TOP

本帖最後由 梁炳 於 2015-12-24 22:13 編輯

你諗多左了,為左唔知有無效既優化,加多個field A
只會簡單複雜化,如果你個程式既logic,md5 hash就係key,咁就只用佢就Okay
DB內部就會自動做indexing (好可能係B+ tree)
換句話講,我建議用Case 1就足夠

如果field A有實際意義,又可以用來縮窄範圍,咁你用Case 2可能會快一點點

TOP

你諗多左了,為左唔知有無效既優化,加多個field A
只會簡單複雜化,如果你個程式既logic,md5 hash就係key ...
梁炳 發表於 2015-12-24 22:09



咁如果就咁用 case1, 個 md5 應唔應該 set index?
因為以前試過做一個 project set 左 index 之後每次 insert/update 都變到好慢, 可能我 set 左太好多, set 得唔好, 但我唔記得果時係 set 左 d 乜, 唔知 set 一個 md5 做 index 會唔會有此問題

TOP

依我有限經驗,如果有index,其實只要條件內無OR之類的條件,速度與你的條件不會有太大關係,電腦唔會咁低能每個record check B是否等於你set個值,而是將值演算做indeX 的數值再找出資料所在上地,一般都很快。加個A是只會越攪越慢。樓主concept有D亂左,要做temp table 加怏速度係啱,但應該係當search條件內有OR之類的運算時使用的。AND之類MySQL自己識得處理。最重要是實際search速度是否好慢,慢就找辦法解決。

TOP

本帖最後由 梁炳 於 2015-12-25 13:28 編輯
咁如果就咁用 case1, 個 md5 應唔應該 set index?
因為以前試過做一個 project set 左 index 之後每次 i ...
cambyliverson 發表於 2015-12-25 00:44


如果你需要經常搜尋,當然要set index
其實係要取捨,睇下你做insert/update多定係search多
你想insert和update快就唔用index,你想搜尋快就用index

當然我唔知你講insert慢係有幾慢
用innoDB engine和間中optimize下個table會有幫助,應該唔會慢得去邊

TOP