❶ 如何提高sql查詢速度
索引對資料庫檢索優化時很重要的一個概念聚集索引在SQL中是唯一的也就是說聚集索引時一個很寶貴的資源但是SQL SERVER在自動分配索引的時候默認總是將ID主鍵分配為聚集索引其實是很浪費的通常情況下你可以通過語句創建聚集索引到你使用率最高的條件欄位上面去，當然你必須先分配聚集索引然後再去分配主鍵，否則主鍵創建時就會自動佔用聚集索引然後非聚集索引不能設置過濫，設置過濫會導致目錄增多最後反而導致查詢緩慢優化不是純粹理論上的東西，理論教會你怎麼去使用嘗試才能獲取經驗
❷ 如何提高SQL語言的查詢效率
由於SQL是面向結果而不是面向過程的查詢語言，所以一般支持SQL語言的大型關系型資料庫都使用一個基於查詢成本的優化器，為即時查詢提供一個最佳的執行策略。對於優化器，輸入是一條查詢語句，輸出是一個執行策略。
一條SQL查詢語句可以有多種執行策略，優化器將估計出全部執行方法中所需時間最少的所謂成本最低的那一種方法。所有優化都是基於用記所使用的查詢語句中的where子句，優化器對where子句中的優化主要用搜索參數(Serach Argument)。
搜索參數的核心思想就是資料庫使用表中欄位的索引來查詢數據，而不必直接查詢記錄中的數據。
帶有 =、<、<=、>、>= 等操作符的條件語句可以直接使用索引，如下列是搜索參數：
emp_id = "10001" 或 salary > 3000 或 a =1 and c = 7
而下列則不是搜索參數：
salary = emp_salary 或 dep_id != 10 或 salary * 12 >= 3000 或 a=1 or c=7
應當盡可能提供一些冗餘的搜索參數，使優化器有更多的選擇餘地。請看以下3種方法：
第一種方法：
select employee.emp_name,department.dep_name from department,employee where (employee.dep_id = department.dep_id) and (department.dep_code='01') and (employee.dep_code='01');
它的搜索分析結果如下：
Estimate 2 I/O operations
Scan department using primary key
for rows where dep_code equals '01'
Estimate getting here 1 times
Scan employee sequentially
Estimate getting here 5 times
第二種方法：
select employee.emp_name,department.dep_name from department,employee where (employee.dep_id = department.dep_id) and (department.dep_code='01');
它的搜索分析結果如下：
Estimate 2 I/O operations
Scan department using primary key
for rows where dep_code equals '01'
Estimate getting here 1 times
Scan employee sequentially
Estimate getting here 5 times
第一種方法與第二種運行效率相同，但第一種方法最好，因為它為優化器提供了更多的選擇機會。
第三種方法：
select employee.emp_name,department.dep_name from department,employee where (employee.dep_id = department.dep_id) and (employee.dep_code='01');
這種方法最不好，因為它無法使用索引，也就是無法優化……
使用SQL語句時應注意以下幾點：
1、避免使用不兼容的數據類型。例如，Float和Integer，Char和Varchar，Binary和Long Binary不兼容的。數據類型的不兼容可能使優化器無法執行一些本可以進行的優化操作。例如：
select emp_name form employee where salary > 3000;
在此語句中若salary是Float類型的，則優化器很難對其進行優化，因為3000是個整數，我們應在編程時使用3000.0而不要等運行時讓DBMS進行轉化。
2、盡量不要使用表達式，因它在編繹時是無法得到的，所以SQL只能使用其平均密度來估計將要命中的記錄數。
3、避免對搜索參數使用其他的數學操作符。如：
select emp_name from employee where salary * 12 > 3000;
應改為：
select emp_name from employee where salary > 250;
4、避免使用 != 或 <> 等這樣的操作符，因為它會使系統無法使用索引，而只能直接搜索表中的數據。
目前,幾乎所有的應用程序都要和資料庫打交道。通過查詢資料庫可很容易地獲得想要的數據。但是,令人不滿意的是:某些查詢時間長,響應速度慢。究其原因,一是硬體設備(如CPU、磁碟)的存取速度跟不上,內存容量不夠大,這需要計算機製造商的努力;另一方面是沒有進行查詢優化
❸ 如何提高SQL語句的查詢效率
1.對查詢進行優化，應盡量避免全表掃描，首先應考慮在 where 及 order by 涉及的列上建立索引。
2.應盡量避免在 where 子句中對欄位進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描，如：
select id from t where num is null
可以在num上設置默認值0，確保表中num列沒有null值，然後這樣查詢：
select id from t where num=0
3.應盡量避免在 where 子句中使用!=或<>操作符，否則將引擎放棄使用索引而進行全表掃描。
4.應盡量避免在 where 子句中使用 or 來連接條件，否則將導致引擎放棄使用索引而進行全表掃描，如：
select id from t where num=10 or num=20
可以這樣查詢：
select id from t where num=10
union all
select id from t where num=20
5.in 和 not in 也要慎用，否則會導致全表掃描，如：
select id from t where num in(1,2,3)
對於連續的數值，能用 between 就不要用 in 了：
select id from t where num between 1 and 3
6.下面的查詢也將導致全表掃描：
select id from t where name like '%abc%'
若要提高效率，可以考慮全文檢索。
7.如果在 where 子句中使用參數，也會導致全表掃描。因為SQL只有在運行時才會解析局部變數，但優化程序不能將訪問計劃的選擇推遲到運行時；它必須在編譯時進行選擇。然而，如果在編譯時建立訪問計劃，變數的值還是未知的，因而無法作為索引選擇的輸入項。如下面語句將進行全表掃描：
select id from t where num=@num
可以改為強制查詢使用索引：
select id from t with(index(索引名)) where num=@num
8.應盡量避免在 where 子句中對欄位進行表達式操作，這將導致引擎放棄使用索引而進行全表掃描。如：
select id from t where num/2=100
應改為:
select id from t where num=100*2
9.應盡量避免在where子句中對欄位進行函數操作，這將導致引擎放棄使用索引而進行全表掃描。如：
select id from t where substring(name,1,3)='abc' // oracle總有的是substr函數。
select id from t where datediff(day,createdate,'2005-11-30')=0 //查過了確實沒有datediff函數。
應改為:
select id from t where name like 'abc%'
select id from t where createdate>='2005-11-30' and createdate<'2005-12-1' //
oracle 中時間應該把char 轉換成 date 如： createdate >= to_date('2005-11-30','yyyy-mm-dd')
10.不要在 where 子句中的「=」左邊進行函數、算術運算或其他表達式運算，否則系統將可能無法正確使用索引。
11.在使用索引欄位作為條件時，如果該索引是復合索引，那麼必須使用到該索引中的第一個欄位作為條件時才能保證系統使用該索引，否則該索引將不會被使用，並且應盡可能的讓欄位順序與索引順序相一致。
12.不要寫一些沒有意義的查詢，如需要生成一個空表結構：
select col1,col2 into #t from t where 1=0
這類代碼不會返回任何結果集，但是會消耗系統資源的，應改成這樣：
create table #t(...)
13.很多時候用 exists 代替 in 是一個好的選擇：
select num from a where num in(select num from b)
用下面的語句替換：
select num from a where exists(select 1 from b where num=a.num)
14.並不是所有索引對查詢都有效，SQL是根據表中數據來進行查詢優化的，當索引列有大量數據重復時，SQL查詢可能不會去利用索引，如一表中有欄位sex，male、female幾乎各一半，那麼即使在sex上建了索引也對查詢效率起不了作用。
15.索引並不是越多越好，索引固然可以提高相應的 select 的效率，但同時也降低了 insert 及 update 的效率，因為 insert 或 update 時有可能會重建索引，所以怎樣建索引需要慎重考慮，視具體情況而定。一個表的索引數最好不要超過6個，若太多則應考慮一些不常使用到的列上建的索引是否有必要。
16.應盡可能的避免更新 clustered 索引數據列，因為 clustered 索引數據列的順序就是表記錄的物理存儲順序，一旦該列值改變將導致整個表記錄的順序的調整，會耗費相當大的資源。若應用系統需要頻繁更新 clustered 索引數據列，那麼需要考慮是否應將該索引建為 clustered 索引。
17.盡量使用數字型欄位，若只含數值信息的欄位盡量不要設計為字元型，這會降低查詢和連接的性能，並會增加存儲開銷。這是因為引擎在處理查詢和連接時會逐個比較字元串中每一個字元，而對於數字型而言只需要比較一次就夠了。
18.盡可能的使用 varchar/nvarchar 代替 char/nchar ，因為首先變長欄位存儲空間小，可以節省存儲空間，其次對於查詢來說，在一個相對較小的欄位內搜索效率顯然要高些。
19.任何地方都不要使用 select * from t ，用具體的欄位列表代替「*」，不要返回用不到的任何欄位。
20.盡量使用表變數來代替臨時表。如果表變數包含大量數據，請注意索引非常有限（只有主鍵索引）。
21.避免頻繁創建和刪除臨時表，以減少系統表資源的消耗。
22.臨時表並不是不可使用，適當地使用它們可以使某些常式更有效，例如，當需要重復引用大型表或常用表中的某個數據集時。但是，對於一次性事件，最好使用導出表。
23.在新建臨時表時，如果一次性插入數據量很大，那麼可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果數據量不大，為了緩和系統表的資源，應先create table，然後insert。
24.如果使用到了臨時表，在存儲過程的最後務必將所有的臨時表顯式刪除，先 truncate table ，然後 drop table ，這樣可以避免系統表的較長時間鎖定。
25.盡量避免使用游標，因為游標的效率較差，如果游標操作的數據超過1萬行，那麼就應該考慮改寫。
26.使用基於游標的方法或臨時表方法之前，應先尋找基於集的解決方案來解決問題，基於集的方法通常更有效。
27.與臨時表一樣，游標並不是不可使用。對小型數據集使用 FAST_FORWARD 游標通常要優於其他逐行處理方法，尤其是在必須引用幾個表才能獲得所需的數據時。在結果集中包括「合計」的常式通常要比使用游標執行的速度快。如果開發時間允許，基於游標的方法和基於集的方法都可以嘗試一下，看哪一種方法的效果更好。
28.在所有的存儲過程和觸發器的開始處設置 SET NOCOUNT ON ，在結束時設置 SET NOCOUNT OFF 。無需在執行存儲過程和觸發器的每個語句後向客戶端發送 DONE_IN_PROC 消息。
29.盡量避免大事務操作，提高系統並發能力。
30.盡量避免向客戶端返回大數據量，若數據量過大，應該考慮相應需求是否合理。
❹ 以下哪種方法執行SQL語句最有效率
優化sql語句執行效率的方法：
1)盡量選擇較小的列
2)將where中用的比較頻繁的欄位建立索引
3)select子句中避免使用『*』
4)避免在索引列上使用計算、not in 和<>等操作
5)當只需要一行數據的時候使用limit 1
6)保證單表數據不超過200W，適時分割表。
針對查詢較慢的語句，可以使用explain 來分析該語句具體的執行情況。
❺ 這兩個sql查詢語句哪個更快
A快。
我覺得不該從聯合查詢的角度考慮。B，C都是進行了兩次搜表查詢，select id from TableA where name like '%b%'，再從所得的結果中select value。
等於對數據搜了兩遍。也就是對第一遍選中的數據，再一次讀取並與第二次的條件比較，而A方法只對同一數據進行了一次比較。如果數據量大的話效率會比較低。
❻ 多表連接查詢和多次單表查詢哪個效率高為什麼
如果數據量小的表，這樣的設計意義不大，而且當然是單錶速度快。若在大數據量情況下，設計非常有意義。在多表連接中注意數據的條目和外健，避免出行大量冗餘數據導致性能下降。下面我以Oracle講講數據查詢的整個過程技術。
由於數據分布到數據塊，在大量數據設計中可以將數據存儲於多個數據塊，在高並發進程的隨機訪問的情況下，能有效減少塊沖突 同樣的數據需要更多的數據塊來存儲，由於數據塊的塊頭元信息大小固定，所以需要更多的空間來存儲塊頭元信息。行長度過大容易導致行連接，從而導致Oracle獲取數據塊的效率降低 ，在行長度固定的前提下，單塊能夠存儲更多的數據行，也就意味著Oracle一次I/O能讀取更多的數據行。適合連續順序讀或者存放大對象數據（如LOB數據） 由於大數據塊可以存放更多的索引葉節點信息，容易引起爭用，所以大數據塊不適合存放索引葉節點信息。
大量數據表的資料庫參數設置DB_FILE_MULTIBLOCK_READ_COUNT表示Oracle一次順序I/O讀操作最多能讀取的數據塊塊數。該參數的默認值隨操作系統的不同而不同。在全表掃描或者索引快速掃描比較多的系統中（如DSS系統），建議將該值設置得較大。但是DB_FILE_MULTIBLOCK_READ_COUNT參數受操作最大單次I/O大小的限制，大多數操作系統單次讀操作的大小不能超過1MB，這也就意味著在8KB數據塊大小的情況下，該參數最大值為128。值得一提的是，該參數的大小還會影響Oracle CBO對執行計劃的評估，如果設成較大值，Oracle的執行計劃傾向於全表掃描。當該參數設置為0或者保持默認時，CBO假設全表掃描時最多能連續讀取8個數據塊。從Oracle 11R2開始，DB_FILE_MULTIBLOCK_READ_COUNT的取值演算法如下：
db_file_multiblock_read_count = min(1048576/db_block_size , db_cache_size/
(sessions * db_block_size))
注意資料庫參數BLOCK_SIZE在設定之後，在資料庫生命周期內不可更改。
當執行SELECT語句時，如果在內存里找不到相應的數據，就會從磁碟讀取進而緩存至LRU末端（冷端），這個過程就叫物理讀。當相應數據已在內存，就會邏輯讀。我物理讀是磁碟讀，邏輯讀是內存讀；內存讀的速度遠比磁碟讀來得快。
下面將本人大數據分區設計截圖，為大家參考學習。
先貼倆圖鎮鎮場。
引言
對於內連接，使用單個查詢是有意義的，因為你只獲得匹配的行。
對於左連接，多個查詢要好得多。
看看下面的基準測試:
5個連接的單個查詢
一行5個查詢
注意，我們在兩種情況下得到了 相同的結果 (6 x 50 x 7 x 12 x 90 = 2268000)
對於冗餘數據，左連接使用更多的內存。
如果只執行兩個表的連接，那麼內存限制可能沒有那麼糟糕，但通常是三個或更多的表，因此值得進行不同的查詢。
用過Laravel嗎？還記得 Eloquent ORM模型嗎？
不知道有沒有注意到，debug所列印出來的多表聯合查詢，
都是拆分為「單個表查詢」，然後使用PHP處理的。
Happy coding :-)
是做表連接查詢還是做分解查詢要具體情況具體分析。
如果資料庫的結構合理，索引設計得當，表連接的效率要高於分解查詢。比如，在有外鍵的時候，資料庫可以為外鍵建表並建立索引從而提升多個表連接查詢的效率。另外，多表連接查詢不需要把數據傳輸到應用程序中，直接在資料庫端執行，這在很大程度上提升了效率。
但是多表連接也有一些缺點。多表連接對表結構的依存度很高，只要表結構出現變更就會同時對資料庫檢索和應用處理兩個部分產生較大影響。另外，多表連接的兼容性不好，資料庫不同SQL文也多少有些差異。而且採用分散資料庫的時候，實現多表連接即麻煩又沒有什麼好處。因此，一些大型系統或者是支持多種類資料庫的系統一般不會使用多表連接，而傾向於採用分解查詢。
這個得看情況，一般數據不大的情況下多表連接查詢和多次單表查詢的效率差不多。如果數據量足夠大，那肯定是多次單表查詢的效率更高。在很多大的公司裡面，都會禁用多表連接查詢，原因就是一旦數據量足夠大的時候多表連接查詢效率會很慢，而且不利於分庫分表的查詢優化。那麼看一下下面這個例子。
兩種查詢方式的比較我這里有一個資料庫，我們拿裡面的客戶表和地區表做兩種查詢的對比。用戶表數據是31萬條，地區表3511條。
1. 使用連表查詢成都市的客戶總數
2.使用多次單表查詢客戶總數
可以看到，查詢出來的結果都是一樣，但是第一種的連表查詢用了0.67秒中，而第二種多次單表查詢一共用時0.14秒。這個對比已經是很明顯了吧。
雖然這只是一個很簡單的例子，但是對比結果是非常明顯的。在實際應用中可能會更復雜、數據更多，如果還使用連表查詢時非常慢的，而且還消耗伺服器資源。
所以現在在很多大了公司明確要求禁止使用join查詢，比如阿里、騰訊就明確規定禁用三表以上的join查詢。
總結一下，單表查詢的優點1. 多次單表查詢，讓緩存的效率更高。
許多應用程序可以方便地緩存單表查詢對應的結果對象。另外對於MySQL的查詢緩存來說，如果關聯中的某個表發生了變化，那麼就無法使用查詢緩存了，而拆分後，如果某個表很少改變，那麼基於該表的查詢就可以重復利用查詢緩存結果了。
2. 將查詢分解後，執行單個查詢可以減少鎖的競爭。
3. 在應用層做關聯，更容易對資料庫進行拆分，更容易做到高性能和可擴展。
4. 查詢本身效率也可能會有所提升。
5. 可以減少冗餘記錄的查詢。
6. 在應用中實現了哈希關聯，而不是使用MySQL的嵌套環關聯，某些場景哈希關聯的效率更高很多。
7. 單表查詢有利於後期數據量大了分庫分表，如果聯合查詢的話，一旦分庫，原來的sql都需要改動。
8. 很多大公司明確規定禁用join，因為數據量大的時候查詢確實很慢
所以在數據量不大的情況下，兩種方式的查詢都沒什麼明顯的差別，使用多表連接查詢更方便。但是在數據量足夠大幾十萬、幾百萬甚至上億的數據，或者在一些高並發、高性能的應用中，一般建議使用單表查詢。
如果覺得笨貓的回答對你有用，點個關注，非常感謝。
做java的，在orm框架下，分解查詢是最符合面向對象操作的，挺支持分解查詢的（拙見）
先說結論：不一定。
多表查詢效率低的時候，可以考慮拆解sql成多個小的sql，至於效率是否一定會提高，這個還不一定，具體問題具體問題。當多表查詢效率低的時候，拆解成單個小sql，這只是一個可能的思路，起不起作用，不一定。
sql是一個很復雜的東西，sql引擎會分析執行計劃，並可能按照他認為最優的執行計劃執行sql，但他認為的也不一定是正確的。不同的sql執行計劃不一樣，所以很難斷定sql拆解或者合並的效率。
說了這么多，那到底是多表聯合查詢還是拆解呢？有沒有一個原則？ 有！如果你確定你的單個sql的執行效率比較快，當然可以寫多個單個sql。當然了，具備這個能力需要你對資料庫足夠了解，比如什麼時候走索引，什麼時候nested loop等等。如果你現在的多表聯合查詢比較慢，你需要找出來慢的原因，並分析拆解後的sql的執行計劃，看是否避免了多表聯合查詢的效率問題。
總之吧。這個問題，只能給你一個大體的思路，因為牽扯到很多基礎問題，我覺得最起碼sql執行計劃應該需要了解，一個sql可能的執行計劃有幾十中，復雜sql的執行計劃又是這幾十種的組合。哪種效率低，哪種效率高應該有個大體了解。
多表查詢可以很快，也可以很慢。主要看執行計劃。
單次肯定是多表連接查詢的效率高，但多次單表查詢的吞吐量高，而且容易優化，例如分庫分表，使用緩存減少DB訪問次數等等，所以在大數據量高並發場景通常使用多次單表查詢的方式。另外，不管是單表還是多表連接查詢，SQL的執行時間和數據量、並發量都有很大關系，和掃描的數據行數也很有關系。如果一條SQL，平時執行一次要2秒，10個並發時，系統可能一點問題都沒有，1000個並發時，資料庫可能就被拖死了。我們組之前碰到過好幾次這種問題，一張只有幾萬條數據的表，因為忘記加索引，平時執行只有幾百毫秒，高峰期直接飆到幾十秒，DB差點被拖垮。
單純從效率來講，join的表不太多時，join效率比較高。但是佔用的主要是資料庫伺服器的資源。資料庫資源又是個瓶頸，不易橫向擴展。所以在數據量大的時候，我們會採用單表查詢，把循環和匹配等大量工作移到應用伺服器上。應用伺服器容易擴展，對並發支持更好。
當數據量大到千萬級以上，就建議盡可能減少join，鼓勵使用單表查詢。查詢優化比較容易。這時候使用join的一個大型查詢就可能花很久，對其他查詢造成阻塞，導致服務不可用。
當考慮單表查詢後，就會衍生一系列的策略，比如冷熱數據分離，將熱數據和 歷史 數據分離，大幅降低數據量級以提高熱數據查詢性能，並可以使用內存緩存。這樣又促使你考慮引入微服務架構。
總結，數據量小，查詢並發少，那麼使用join的性能是可控的，開發成本低。當數量級上升到千萬級且不斷增加，盡早考慮向單表查詢切換，否則可能有性能下降會導致系統奔潰。而且性能下降不是線性的，會陡降。
❼ 如何加快sql資料庫查詢速度
第1條語句：建議把子查詢（SELECT gsid, max(dateandtime)as dt from info group by gsid ) i2 on i1.gsid = i2.gsid and i1.dateandtime = i2.dt)創建成一個視圖VIEW，看看能不能加快查詢，你可以試試，我這里沒有你的數據無法測試，經驗之談，希望對你有幫助
其他的優化方法你可以考慮根據你的表情況從索引和jsp頁面緩存的角度改善這個問題，具體的可以HI我，我們詳談。
❽ 在sql語句查詢時，自聯接查詢的快還是子查詢快最好給出具體的分析。
這要看
子查詢
的類型，如果是相關子查詢的話，
時間復雜度
和
自連接
是同一級別的，如果是非相關子查詢，那一般情況下是非相關子查詢快，詳細可聯系我。