MySQL JOIN vs LIKE - 更快的選擇？

Question

好的，首先讓我告訴一下我想要做的事情。基本上，在我的學習期間，我用PHP編寫了一個小型Web服務，根據長度，演員，導演，作家，流派等一些可測量的尺寸計算相似電影之間的相似程度。我用於此的數據基本上是一組數據從omdbapi.com獲得。

我還有那個數據庫，但它在技術上只是一個包含所有到每部電影的信息的單表。這意味着，對於每部電影，上述所有參數均以逗號分隔。因此，我迄今使用了一個使用LIKE語句封裝所有這些東西的查詢。該查詢可能會變得非常大，因爲我幾乎會查詢表中的每個參數，有時針對不同演員的5個不同的LIKE語句，對於導演和作者而言也是如此。當我上次使用此功能時，大約需要30到60秒才能輸入一部電影並收到15個類似電影的列表。

現在我開始了自己的第一份工作，並在自由時間自學自我，我想在自己的網站上工作。因爲我沒有真正的想法來處理我想要做的事情，所以我想我會再次拿出我的老電影發現者，並且這次使用它。 現在要挑戰自己，我希望整個事情變得更快。瞭解，數據從未改變，只能閱讀。這也不是「真正」的關係，因爲演員的名字和其他只是字符串，並沒有其他地方真正的進入。這意味着具有相同的名字將被視爲同一個演員。

現在，這裏是我的實際問題： 假設我想我的選擇查詢更快地運行，這將是有意義的運行，其將逗號分隔字符串成額外的表腳本（這些是n到m的關係，看到的嘗試下面），然後加入所有這些表（他們將是8或更多），或將使用LIKE，因爲我目前的速度相同？我試圖實現的唯一的事情是更快的選擇查詢，因爲沒有其他任何事情可以處理數據。

這是我現在有。請記住，我仍然必須爲電影+每個表格之間的關係創建表格。這樣做後，我可以刪除電影表中的列，並最終不得不通過每個查詢加入很多表格。我在這裏可以看到的唯一真正的好處是，在個人表格上創建索引會比較容易，而不是一個（或幾個）索引，以覆蓋大型電影表格。

我希望所有這些都對你有意義。我很欣賞任何短或長的答案，就像我說的這主要是爲了自學，因此我不需要一個真正的商業模式。

Answer 1

我不明白你目前有什麼。看起來你只顯示錶格的大小，而不顯示其內部結構。您需要使用規範化規則將數據分隔到不同的表中，然後放入正確的索引。索引將使您的查詢速度非常快。你的查詢上面的大小是什麼意思？您是否曾經爲您的查詢運行過EXPLAIN ANALYZE，並請發佈查詢，我無法從結果中猜出您的查詢。 YT上有很多優化視頻。