『壹』 sql中多表聯合查詢用什麼方法效率最高
關聯條件最好是主鍵或者有索引的列，然後可以用小表左關聯大表。
『貳』 MySQL高性能SQL注意事項簡述
資料庫作為應用開發中必不缺少的基礎設施，其性能直接影響應用的整體運行速度。MySQL是目前最廣泛使用的關系型資料庫之一，對於開發人員寫出性能良好的SQL是必備的基本技能之一。下面簡單描述下編寫SQL的注意事項。
編寫高質量的SQL需要從以下幾個方面注意，基本原則、表欄位注意事項、索引使用注意事項、SQL注意事項。
基本原則
一、盡量不要在資料庫里做運算。如果遇到運算盡可能在應用程序層進行計算。
二、控制資料庫表數量、控制單表數據量、控製表的欄位數。建議單庫不要超過四百張表，建議單表欄位不要超過五十個，建議單表的數據量不要超過一千萬。
三、不要編寫大SQL、不要使用大事務。SQL盡量寫的簡單點拒絕編寫大SQL，可以將大SQL拆分成多個小SQL，在應用層聚合。大事務拆分成多個小事務，快速提交。
表欄位注意事項
一、選擇合適數值欄位類型。能用小欄位類型的就用小欄位類型，如tinyint就比int(1)在表示小數據時合適。
二、能用數字表示就不要用字元。如可以用無符號INT存儲IP而不是字元串表示。
三、避免使用NULL欄位。原因NULL欄位查詢優化難，含NULL復合索引失效。
四、少用或拆分TEXT/BLOB欄位。欄位太大需要更多的空間，性能低下，如需使用拆分到單獨表。
五、不要在表欄位中存儲圖片。
索引使用注意事項
一、合理添加索引。索引添加太多會影響更新速度。能夠使用復合索引的避免加多個單獨索引。
二、字元欄位建立前綴索引。
三、不在索引列做運算。索引列做運算會導致索引失效。
四、盡量不使用外建。
SQL類注意事項
一、 SQL語句盡可能簡單。大SQL拆分成多個小SQL。
二、事務編寫盡量短小。事務即開即用用完立即關閉。
三、盡量不要使用select *。只取需要的列。
四、改寫OR為IN或者改寫為UNION操作。OR在數據量大的時候性能低於IN。
五、避免NOT、!=、>、NOT IN、NOT EXISTS、NOT LIKE等查詢。
六、避免%前綴模糊查詢。
七、能用UNION ALL不要用UNION。
八、GROUP BY中去除排序。自帶排序。
九、同類型的欄位做比較。字元類和字元類比較，數值類和數值類比較，不要混在一起比較。
十、盡量單表查詢，盡量不要多表關聯查詢。多表關聯查詢可以拆分成單表查詢在應用程序中聚合數據。
十一、復合索引的多列注意最左原則。
上述注意事項能避免很多性能低下的SQL，希望在開發過程中能引起注意。
『叄』 多表關聯查詢的SQL執行原理
平時大多是執行單表查詢，通常你把索引建好，讓他盡可能走索引，性能都沒問題。但其實也有不少的多表關聯語句，因為有時查找目標數據，不得不藉助多表關聯的語法，才能實現你想要但使用多表關聯的時候，你的SQL性能就可能會遇到一些問題。
若在FROM字句後直接來兩個表名，就是要針對兩個表進行查詢，而且會把兩個表的數據給關聯，假設你未限定多表連接條件，可能會搞出一個笛卡爾積。所以通常都會在多表關聯語句中的WHERE子句里引入一些關聯條件：where t1.x1=xxx and t1.x2=t2.x2 and t2.x3=xxx
假設：
所以該SQL執行過程可能是：
他可能是先從一個表裡查一波數據：驅動表
再根據這波數據去另外一個表裡查一波數據進行關聯，另外一個表叫：被驅動表
員工表包含id（主鍵）、name（姓名）、department（部門）
產品銷售業績表裡包含id（主鍵）、employee_id（員工id）、產品名稱（proct_name）、銷售業績（saled_amount）。
現在要看每個員工對每個產品的銷售業績：
此時看到的數據：
全表掃描員工表，找出每個員工，然後針對每個員工的id去業績表找 employee_id 跟員工id相等的數據，可能每個員工的id在業績表裡都會找到多條數據，因為他可能有多個產品的銷售業績。
然後把每個員工數據跟他在業績表裡找到的所有業績數據都關聯，比如:
內連接，inner join，要求兩個表裡的數據必須完全能關聯上，才能返回。
假設員工表裡有個人是新員工，入職到現在無銷售業績，此時還是希望能夠查出來該員工的數據，只不過他的銷售業績那塊可以給個NULL，表示無業績。但若僅使用上述SQL語法，似乎搞不定，因為必須要兩個表能關聯上的數據才查得出來。
此時就需要
outer join，分為：
還有個語法限制，如果你是內連接，那連接條件可以放在where語句，但外連接一般是把連接條件放在ON語句：
一般寫多表關聯，主要就是內連接和外連接。
『肆』 sql語句多表聯查，查詢速度太慢，超過10s，由於是菜鳥，不知道怎樣優化
確定是菜鳥，sql 寫成這樣 證明你邏輯很清楚啊，建議如果是初學者，代碼規范一定要保持
不知道代碼規范，可以去窗口format一下。。。
言歸正傳 你這個優化的話 可以把
AND p.mediatypeinfoid in (
select
id
from
fn_get_mediatype_infor(5)
)
上面這部分 換成 inner join
『伍』 關於SQL Server多表查詢性能問題
第二條 語句更好 ；
你第一條 得執行兩次，需要訪問資料庫兩次，浪費資源；
第二種訪問資料庫一次就好了，高下立判。
建議第一種可以用 union all連接起來，效率會提高，但仍然沒有第二種效率高。
『陸』 oracle 對於多個大表關聯操作如何優化速度
1、首先要建立適當的索引。sql在索引欄位不要加函數，保證索引起效。如果是復合索引注意在sql的順序。如果已經存在索引，建議你先重建索引先，因為大數據表的索引維護到了一個階段就是亂的，一般建議重建。建立好的一般可以獲得幾十倍的速度提升。
2、最大數據量的表放在最前，最小的表放在最後面。sql是從最後面開始反向解析的。
3、其次是要把最有效縮小范圍的條件放到sql末尾去。尤其是主鍵或者索引欄位的條件。
4、保證你sql的演算法合理性。保證復雜度和空間度的合理性。
5、必要時候使用存儲過程。提升30%-40%的速度
6、建議你分頁讀取不要一下讀完所有的數據。（使用rownum），一下子數據太多會使得內存不夠用的。
如果這些都做了還不滿意的話，可以考慮建立幾個表空間，然後按照一個演算法將各個表的數據，平均的放在各個表空間內（分表分區），在select的時候資料庫就會使用多線程到各個表空間索引數據，這個一般不是上千萬級的表是不用的。 也不是所有人都會用。
『柒』 一句sql連了很多表 效率慢，怎麼提高效率
關聯代碼表不會特別影響效率。
正常遇到這類問題是 看執行計劃怎麼樣，是不是和想像中的不一致
針對有問題的部分想辦法處理 比如建索引表或者 hints 等