2014-08-27 35 views
0

我相信這個問題已在很多方面被問過,但我找不到一個答案,全面地闡述了我的具體情況 - 所以這裏。建立一個搜索過程 - MySQL - 喜歡與多個價值觀與LIKE與臨時表

我正在跨多個表和字段構建搜索功能。有一個表用於存儲個人信息,另一個表用於存儲他們的地址信息,另一個表用於存儲他們的電話信息。

屏幕提供關鍵字輸入 - 這將觸發搜索。用戶可以輸入一個關鍵字或用逗號隔開的關鍵字

正如我評估各種選項,這裏是我想出了

  1. 做一個存儲過程內的搜索,因爲搜索查詢運行鍼對多個不同表和不同的字段 - 這個完整的SQL邏輯最好保存在數據庫層中。
  2. 將關鍵字以逗號分隔或用管道分隔的字符串的形式發送到PHP的存儲過程 - 因此,所有關鍵字的預處理都以PHP完成
  3. 讓存儲過程處理搜索查詢並返回組合結果集,可以很容易地顯示

我有多個選項設計存儲過程,而這正是我要尋找的提醒/輸入從社區

用途需要多大看完後對REGEXP,我決定使用LIKE選項來匹配關鍵字agai nst數據庫中的各種屬性,然後生成結果集的UNION針對各種表發送回

優點 - LIKE是非常快。這是非常簡單的使用和完成工作

缺點 - 如果用戶輸入多個關鍵字,然後邏輯變得非常複雜,因爲我必須在存儲過程中生成多個OR LIKE %keyword%語句。另一種選擇可能是使用臨時表並將每個關鍵字搜索的結果插入同一個

問題 - 使用臨時表是否顯着降低了存儲過程的性能?要匹配的平均行數範圍在8000到10000之間,最大限制可能是100000.

因此,如果我使用WHILE循環搜索每個關鍵字並將結果插入到表中,那麼性能會顯着下降一個臨時表,而不是動態生成OR LIKE語句並運行單個查詢。

+0

LIKE並不總是很快,事實上,LIKE真的可以減慢速度。 WH使用前面帶有通配符的like語句,即'LIKE'%someterm%''MySQL不能使用索引,因此將執行表掃描。一旦你開始縮放,你就會大大減慢速度。除非你絕對必須,否則不要使用LIKE – Namphibian 2014-08-27 21:54:53

回答

0

截至目前,我已經決定用刀片去提前到一個臨時表的原因如下

  1. 在查詢語句的複雜性,而不是多個LIKE語句 - 多LIKE條款只是創造了一個非常複雜的存儲過程設計和結果查詢
  2. 單個查詢可能與一個大型複雜查詢一樣高效 - 即使存在折衷,我懷疑它會很小。我還沒有用實時數據測試過,但一旦我有足夠的音量就會發布更新。