㈠ automicdata的sql搜尋語句中快的原因是什麼
原因就是通過事先排好序，從而在查找時可以應用二分查找等高效率的演算法。一般的順序查找，復雜度為O(n)，而二分查找復雜度為O(log2n)。當n很大時，二者的效率相差及其懸殊。 舉個例子:表中有一百萬條數據，需要在其中尋找一條特定id的數據。如果順序查找，平均需要查找50萬條數據。而用二分法，至多不超過20次就能找到。二者的效率差了2.5萬倍!
㈡ SQL執行與優化
SQL優化
執行計劃,表關聯查詢順序,優化策略與思路
下面再向前走一些，容我根據自己的認識說一下查詢執行的流程是怎樣的：
1.連接
1.1客戶端發起一條Query請求，監聽客戶端的『連接管理模塊』接收請求
1.2將請求轉發到『連接進/線程模塊』
1.3調用『用戶模塊』來進行授權檢查
1.4通過檢查後，『連接進/線程模塊』從『線程連接池』中取出空閑的被緩存的連接線程和客戶端請求對接，如果失敗則創建一個新的連接請求
2.處理
2.1先查詢緩存，檢查Query語句是否完全匹配，接著再檢查是否具有許可權，都成功則直接取數據返回
2.2上一步有失敗則轉交給『命令解析器』，經過詞法分析，語法分析後生成解析樹
2.3接下來是預處理階段，處理解析器無法解決的語義，檢查許可權等，生成新的解析樹
2.4再轉交給對應的模塊處理
2.5如果是SELECT查詢還會經由『查詢優化器』做大量的優化，生成執行計劃
2.6模塊收到請求後，通過『訪問控制模塊』檢查所連接的用戶是否有訪問目標表和目標欄位的許可權
2.7有則調用『表管理模塊』，先是查看table cache中是否存在，有則直接對應的表和獲取鎖，否則重新打開表文件
2.8根據表的meta數據，獲取表的存儲引擎類型等信息，通過介面調用對應的存儲引擎處理
2.9上述過程中產生數據變化的時候，若打開日誌功能，則會記錄到相應二進制日誌文件中
3.結果
3.1Query請求完成後，將結果集返回給『連接進/線程模塊』
3.2返回的也可以是相應的狀態標識，如成功或失敗等
3.3『連接進/線程模塊』進行後續的清理工作，並繼續等待請求或斷開與客戶端的連接
接下來再走一步，讓我們看看一條SQL語句的前世今生。
首先看一下示例語句
示例語句
執行順序
SQL解析
1. FROM
當涉及多個表的時候，左邊表的輸出會作為右邊表的輸入，之後會生成一個虛擬表VT1。
(1-J1)笛卡爾積
計算兩個相關聯表的笛卡爾積(CROSS JOIN) ，生成虛擬表VT1-J1。
兩次全表掃描
哈希索引,查找復雜度都是 O(1) 。
2. WHERE
對VT1過程中生成的臨時表進行過濾，滿足WHERE子句的列被插入到VT2表中。
注意：
此時因為分組，不能使用聚合運算；也不能使用SELECT中創建的別名；
與ON的區別：
如果有外部列，ON針對過濾的是關聯表，主表（保留表）會返回所有的列；
如果沒有添加外部列，兩者的效果是一樣的；
應用：
對主表的過濾應該放在WHERE；
對於關聯表，先條件查詢後連接則用ON，先連接後條件查詢則用WHERE；
hash join 哈希連接 驅動表和被驅動表都只會訪問0次或1次
應用場景:一個大表一個小表/表上沒有索引/返回結果集比較大
3. GROUP BY
這個子句會把VT2中生成的表按照GROUP BY中的列進行分組。生成VT3表。
注意：
其後處理過程的語句，如SELECT,HAVING，所用到的列必須包含在GROUP BY中，對於沒有出現的，得用聚合函數；
原因：
GROUP BY改變了對表的引用，將其轉換為新的引用方式，能夠對其進行下一級邏輯操作的列會減少；
原作者的理解是：
根據分組欄位，將具有相同分組欄位的記錄歸並成一條記錄，因為每一個分組只能返回一條記錄，除非是被過濾掉了，而不在分組欄位裡面的欄位可能會有多個值，多個值是無法放進一條記錄的，所以必須通過聚合函數將這些具有多值的列轉換成單值；
GROUP BY 重新聚合查詢
4. HAVING
這個子句對VT3表中的不同的組進行過濾，只作用於分組後的數據，滿足HAVING條件的子句被加入到VT4表中。
7.LIMIT
LIMIT子句從上一步得到的VT6虛擬表中選出從指定位置開始的指定行數據。
注意：
offset和rows的正負帶來的影響；
當偏移量很大時效率是很低的，可以這么做：
採用子查詢的方式優化，在子查詢里先從索引獲取到最大id，然後倒序排，再取N行結果集
採用INNER JOIN優化，JOIN子句里也優先從索引獲取ID列表，然後直接關聯查詢獲得最終結果
當前未用到索引,
三次full scan , table1 AS a / table2 AS b / GROUP BY
盡量少做重復的工作
控制同一語句的多次執/減少多次的數據轉換/
杜絕不必要的子查詢和連接表，子查詢在執行計劃一般解釋成外連接，多餘的連接表帶來額外的開銷
關於臨時表和表變數的選擇
臨時表產生使用SELECT INTO和CREATE TABLE + INSERT INTO的選擇，一般情況下，SELECT INTO會比CREATE TABLE + INSERT INTO的方法快很多，但是SELECT INTO會鎖定TEMPDB的系統表SYSOBJECTS、SYSINDEXES、SYSCOLUMNS，在多用戶並發環境下，容易阻塞其他進程，所以建議，在並發系統中，盡量使用CREATE TABLE + INSERT INTO，而大數據量的單個語句使用中，使用SELECT INTO。
子查詢的用法
相關子查詢可以用IN、NOT IN、EXISTS、NOT EXISTS引入
NOT IN、NOT EXISTS的相關子查詢可以改用LEFT JOIN代替寫法
如果保證子查詢沒有重復 ，IN、EXISTS的相關子查詢可以用INNER JOIN 代替
IN``的相關子查詢用EXISTS代替
不要用 COUNT (*)的子查詢判斷是否存在記錄，最好用 LEFT` `JOIN 或者EXISTS，比如有人寫這樣的語句：
建立索引後，並不是每個查詢都會使用索引，在使用索引的情況下，索引的使用效率也會有很大的差別。只要我們在查詢語句中沒有強制指定索引，
不要對索引欄位進行運算，而要想辦法做變換
不要對索引欄位進行格式轉換
不要對索引欄位使用函數
不要對索引欄位進行多欄位連接
join關聯查詢的計算是很復雜的，特別是數據量比較大的情況下，實際情況還是拆解較快的
Join拆解的核心就是利用In關鍵字
要麼用空間換時間，要麼用時間換空間
多表連接的連接條件對索引的選擇有著重要的意義，所以我們在寫連接條件條件的時候需要特別注意。
A、多表連接的時候，連接條件必須寫全，寧可重復，不要缺漏。
B、連接條件盡量使用聚集索引
C、注意ON、WHERE和HAVING部分條件的區別
ON是最先執行， WHERE次之，HAVING最後，因為ON是先把不符合條件的記錄過濾後才進行統計，它就可以減少中間運算要處理的數據，按理說應該速度是最快的，WHERE也應該比 HAVING快點的，因為它過濾數據後才進行SUM，在兩個表聯接時才用ON的，所以在一個表的時候，就剩下WHERE跟HAVING比較了
考慮聯接優先順序：
(1)INNER JOIN
(2)LEFT JOIN (註：RIGHT JOIN 用 LEFT JOIN 替代)
(3)CROSS JOIN
索引並不適用於所有情況：a.少量數據；b.頻繁進行改動的欄位，不適合做索引；c.很少使用的欄位，不需要加索引
索引會提高數據查詢效率，但是會降低「增、刪、改」的效率。當不使用索引的時候，我們進行數據的增刪改，只需要操作源表即可，但是當我們添加索引後，不僅需要修改源表，也需要再次修改索引，很麻煩。
先執行順序, 是否走索引, 有無類型轉換
18000 字的SQL優化大全
步步深入：MySQL架構總覽->查詢執行流程->SQL解析順序
MySQL索引總結（4）——btree與hash區別
㈢ oracle sql語法 in 的疑問
簡單來講這是一個書寫不規范的SQL語句，容易讓人產生歧義。對於多表的嵌套查詢規范是每個表都要有別名，指定欄位時更要指定是哪個表的欄位，這樣的代碼才清晰易讀。
復雜來講就是人可能產生歧義，但機器不會。寫這個語句的人就是利用了機器運行語句時的邏輯去寫的代碼，更多的是為了增加代碼復雜度，妨礙他人閱讀理解他的代碼。或者就是這個人的編碼習慣就是如此，具有某種編碼強迫症。
㈣ 求SQL表擴展欄位屬性的思路
大家在使用SQL Server開發的時候一定會遇到這樣的需求，那就是通過Table_Name1表的兩個欄位Column1、Column2來查詢在Table_Name2表中符合這兩個條件的記錄，並返回Table_Name2中的欄位Column3，面對這樣的需求，你也許會說使用表連接就可以了，對的，沒錯，我也是這樣想的，但是有的時候往往要面對不同的突發情況，那就是並不是一定會Column1與Column2是全匹配的查詢，可能中間還需要一些邏輯的處理，比如字元串的截取後再匹配等等。這個時候我們通常會在SQL Server中寫一個函數，這個函數接收兩個參數：Column1、Column2，函數體裡面做一些邏輯處理，在通過處理好的參數去查詢Table_Name2表，並返回相應的值。很好，那下面我們來計算下圖中數據的查詢情況。假設表1的數據有50W，表2的數據有4W，在表2沒有索引的條件下，查詢的復雜度就有50W*4W了，兩個表都需要做全表掃描，表2的全表掃描就會達到50W次。（圖1：需求說明）優化1：這一個優化，每個開發人員都知道，那就是對表2的兩個查詢欄位分別建立索引。這樣的優化和之前相比，性能將會提高N個等級。優化2：這第二個優化方法是使用SQL Server的復合索引，在表2上創建一個復合索引，這個符合索引包括需要查詢的兩個欄位，其實就是把兩個欄位的內容生成一個索引，其中索引包含了兩個索引的排序。優化3：這第三個優化方法是使用SQL Server2005之後版本才有的索引-包含性索引（Include），就是在優化2的基礎上，把需要返回的欄位也一起放入到索引中，這樣的查詢就只需要查詢索引就夠了，不需要再讀取數據頁了，減少磁碟的IO消耗。不過這個方法也不是萬能，因為有時可能返回的欄位會比較多，有時幾個欄位加起來的長度有可能超出了900個字元（索引大小范圍），如果想了解可以進入：SQL Server 索引中include的魅力（具有包含性列的索引）優化4：在不考慮一些分區、分表、分到不同的磁碟等優化方式的情況下，我們是否還能進一步優化我們的查詢呢？這就是這篇文章想要告訴你的，因為我們的回答是：有的。那就是通過SQLCLR的UDT，把表2的數據一次性載入到內存，那麼在進行表1查詢的時候，我們不需要通過B+樹來查詢數據了，直接到內存中查詢，這樣之所以快是因為操作內存要比操作磁碟要快得多。這其中會有些局限性和缺點，具體見下面的缺點描述。設計思路1、去資料庫中把表2讀取出來，並放到private static readonly IDictionary<string, string> resultCollectionDic的靜態變數中。在資料庫服務啟動的時候是會初始化2、SQLCLR函數的，所以在啟資料庫服務的時候，也一起把表2的數據保存到了內存當中了。3、上面的查詢中包括了兩個欄位Column1、Column2和一個返回欄位Column3，那麼我們如何把這些數據保存到IDictionary字典當中呢？我的做法就是把Column1、Column2的中間加一個字元「+」，把這個字元串作為Key值，把Column3這個返回值做為Value，這樣就解決了多個And的查詢的問題。這個會有些局限性，具體可以見下面的缺點描述。在函數FunctionImsi2HLR2中傳進的兩個字元後，就要進行上面的拼湊方式來拼湊Key值，再到IDictionary中查詢。
㈤ SQL Server中視圖有什麼用，而非語法格式請高人指點
前段時間作項目中，遇到使用視圖的問題，以前的工作中很少遇到視圖，認為直接用表就ok了，何須視圖呢？下面我來講述一下它的功用：以往當我們查詢數據時，一定要很認真的地從設計select語句開始，將需要查詢的每個欄位寫在sql語句里，每次你要以同樣的條件來查詢數據時，那麼每次都要重復輸入相同的查詢語句，效率很低。若將這個經常要重復使用的查詢語句創建成視圖，就不用那麼麻煩了！直接用select * from 視圖名 就行了，其實將查詢語句創建成視圖，不僅僅是簡化查詢的動作；更重要的是，視圖具備數據表的特性，還可以衍生出更多的應用。
所謂視圖（View）其實是執行查詢語句後得到的結果，但這個查詢結果可以模擬成數據表來使用，所以有人也稱它為「虛擬數據表」，視圖在操作上和數據表沒有什麼區別，但兩者的差異是其本質是不同的：數據表是實際存儲記錄的地方，然而視圖並不保存任何記錄，它存儲的實際上是查詢語句，其所呈現出來的記錄實際來自於數據表，可以為多張數據表，大家由此可以預見到視圖應用的彈性！我們可以依據各種查詢需要創建不同視圖，但不會因此而增加資料庫的數據量。
下面總結視圖的幾大優點：1.增強可讀性 2.數據安全及保密：針對不同用戶，可以創建不同視圖，限制其所能瀏覽和編輯的數據內容。3.降低查詢復雜度 4.方便維護。
總之，善於運用視圖可以讓資料庫的設計、管理及使用都更加有效率、更加方便。
㈥ SQL連表查詢跟一個個表查詢那個快各有什麼優點和缺點
SQL鏈接表查詢稱為聯合查詢，表查詢是單個查詢。其區別和優點如下：
1．從發展效率的角度看：
聯合查詢是需要多個單查詢邏輯組合才能完成的查詢工作，聯合查詢只需要一個SQL就可以完成查詢工作，即將業務邏輯轉化為SQL，由資料庫來處理，相對來說，開發效率會更高。
2．從查詢效率來看：
單個查詢具有更好的可重用性，因此比聯合查詢更有效。
當讀取或寫入資料庫時，資料庫使用鎖機制來限制其他連接對其進行操作。由於聯邦查詢比單個查詢慢得多，它們會增加鎖爭用，因此單個查詢更好。
3．從邏輯結構層面來看，分層原則
關聯表示業務規則／邏輯。如果經常使用關聯查詢，就會將大量的業務規則和邏輯放入資料庫中執行，這將大大增加CPU、內存、IO等資源的消耗。
4．從資源利用的角度來看
在大多數情況下，並不是所有相關查詢的結果都得到了有效的使用。例如，後台管理的列表界面會顯示分頁、關聯查詢的結果集，只使用當前頁面的數據，而資料庫需要消耗額外的資源才能得到整個結果集。
5．從架構的可伸縮性的角度來看
大量的相關查詢將導致集中式資料庫體系結構難以轉化為分布式體系結構，可擴展性優化也難以實現。關聯查詢方便快捷，開發效率更高。
不使用關系查詢在體系結構級別上有很多優勢，但是它需要大量的系統分析、設計和開發功能。一般在互聯網行業，如用戶數量最好重視這方面。
由於數據量小，兩個查詢的效率基本沒有差別，但在實際應用中，需要根據數據量、業務復雜度等進行綜合評價。
㈦ 在sql語句查詢時，自聯接查詢的快還是子查詢快最好給出具體的分析。
這要看
子查詢
的類型，如果是相關子查詢的話，
時間復雜度
和
自連接
是同一級別的，如果是非相關子查詢，那一般情況下是非相關子查詢快，詳細可聯系我。
㈧ SQL連表查詢跟一個個表查詢那個快各有什麼優點和缺點
SQL連表查詢稱為聯合查詢，一個個表查詢是單查詢。兩者的區別和優缺點如下：
1、從開發效率來看：
聯合查詢是需要多個單查詢進行邏輯組合才能完成的查詢的工作，聯合查詢僅僅需要一個SQL就可以完成查詢工作，即把業務邏輯放到了SQL中，由資料庫來處理，相對來說開發效率會比較高些。
2、從查詢效率來看：
單查詢的可重用性較高，所以效率相較之聯合查詢會更高。
在資料庫進行讀寫時，資料庫會用鎖機制，限制其他連接對其操作。由於聯合查詢查詢速度比單個查詢要慢很多，這樣聯合查詢會增加鎖的競爭關系，所以用單查詢會更好。
3、從邏輯架構分層原則來看
關聯關系代表了業務規則/邏輯，如果大量使用關聯查詢，就是把大量的業務規則和邏輯放在資料庫來執行了，資料庫消耗cpu、內存、io等資源會大大增加。
4、從資源利用率方面看
大部分場景下，並不是所有關聯查詢的結果都被有效使用了。例如後台管理的列表界面會分頁顯示，關聯查詢的結果集，只有當前頁的數據被使用，但資料庫需要消耗額外資源得到全部結果集。
5、從架構的伸縮性方面看
大量的關聯查詢會導致集中式的資料庫架構很難向分布式架構轉換，伸縮性方面的優化難度高。關聯查詢方便快速，開發效率比較好。
不使用關聯查詢在架構層面有很多優點，但對系統分析和設計、開發能力要求高。一般在互聯網行業等用戶數較多的情況下最好重視這方面。
題主的兩個查詢由於數據量不多，效率上基本沒有差別，但在實際應用中要根據數據量、業務復雜度等去綜合評估。
㈨ sql2005如何根據三個表聯合查詢出的結果對其中一個表進行操作
這要看你這三個表聯合查詢的復雜度
如果這三個表只是一般的聯合查詢，可以直接操作。
如你可以將三個表的查詢結果作為一個派生表再與你要操作的表進行關聯操作。
㈩ sql 表多好還是表少好
分表的好壞不是這么絕對的事,有很多的限制因素:
1.數據的分布情況,若數據是均勻分布在各類型中那麼可以有效的分散操作,在某種程度上可以增加檢索速度,但是如果分布是不均勻的某種類型的數據很多,遠大於其他類型那麼採用分表就沒什麼意義了,操作還是會集中於某一張表同是還增加了系統的復雜度,系統羅輯復雜,得不嘗矢.
2.分表只是表面上的展現,實即上最能提高性能的是物理上的存儲分離,若只是單純的將表分了,但物理IO還是作用於同一塊硬碟實即上是提高不了多少性能的.
3.而且分表對CPU等硬體也有要求,若CPU是雙核的肯定比單核的CPU分表效果好,資料庫可以雙線程掃描多塊硬碟才是分表的初衷.
4.而且從你的描述來看,分表的關健字也值得考慮下,分表基於的關健字會在很大程度上影響查詢的效率,見譯多實驗.本人做過每天400萬的數據,要求最少保存3個月,才用的就是按天分表,效果還不錯,但是業務羅輯相應的會復雜些需要考慮周全.
先只能想到這么多,希望對你有幫助.