MySQL檢視是否比複雜查詢更有效率?
P粉237689596
P粉237689596 2024-01-10 17:09:15
0
1
363

我在使用多個內連接的SELECT語句時遇到了問題。我的程式碼如下:

SELECT `movies02`.`id`, `movies02`.`title`,
       `movies03`.`talent`, 
       `movies07`.`character`,
       `movies05`.`genre`
  FROM `movies02`
 INNER JOIN `movies07` ON `movies07`.`movie` = `movies02`.`id`
 INNER JOIN `movies03` ON `movies03`.`id` = `movies07`.`performer`
 INNER JOIN `movies08` ON `movies08`.`genre` = `movies05`.`id`
 INNER JOIN `movies02` ON `movies08`.`movie` = `movies02`.`id`;

使用INNER JOIN獲取電影中的演員以及他們扮演的角色似乎可以工作,但是獲取電影類型的後兩個連接不起作用,所以我想我可以將它們寫成一個視圖,然後在輸出結果時將它們組合起來。因此,我最終會得到三個視圖。一個用於獲取類型、演員和角色,然後一個用於將所有內容組合在一起。問題是,這樣做是否比使用一個大型的SELECT語句和多個連接更好?

我嘗試了多次重寫查詢,並以多種方式進行了嘗試

P粉237689596
P粉237689596

全部回覆(1)
P粉827121558

當你執行涉及視圖的查詢時,MySQL / MariaDB的查詢計劃器會將所有視圖和主查詢組合成一個單獨的查詢,然後再決定如何存取表。因此,使用視圖、公共表達式和/或子查詢時,效能基本上相同

也就是說,視圖是封裝一些查詢複雜性的有用方式。

而且,您可以授予部分受信任的使用者對視圖的存取權限,而無需授予他們對底層表的存取權限。

視圖的缺點與將任何應用邏輯放入資料庫管理系統而不是應用程式中的缺點相同:更新更加棘手,更容易忘記更新。 (如果您有一個可靠的應用程式更新工作流程,可以在更新應用程式程式碼時更新視圖、儲存函數和預存過程,則此問題不相關。)

也就是說,編寫此類查詢的一個好方法是從包含「頂級」實體的表開始。在您的情況下,我認為是電影。然後使用LEFT JOIN連接其他表,而不是使用INNER JOIN。這樣,即使某些子實體(演員、類型等)缺失,您仍然可以在結果中看到電影。

專業提示:如果可以的話,為包含的實體(電影、類型、演員等)命名表,而不是使用whatever01whatever02之類別的名稱。能夠查看查詢並進行推理非常重要,而表名可以使這一點更容易。

熱門教學
更多>
最新下載
更多>
網站特效
網站源碼
網站素材
前端模板
關於我們 免責聲明 Sitemap
PHP中文網:公益線上PHP培訓,幫助PHP學習者快速成長!