Ⅰ 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區別
Ⅱ mssql2000版本用戶hash獲取的sql語句是
查詢Oracle正在執行的sql語句及執行該語句的用戶
SELECT b.sid oracleID, b.username 登錄Oracle用戶名, b.serial#, spid 操作系統ID, paddr, sql_text 正在執行的SQL, b.machine 計算機名FROM v$process a, v$session b, v$sqlarea cWHERE a.addr = b.paddr AND b.sql_hash_value = c.hash_value
查看正在執行sql的發起者的發放程序
SELECT OSUSER 電腦登錄身份, PROGRAM 發起請求的程序, USERNAME 登錄系統的用戶名, SCHEMANAME, B.Cpu_Time 花費cpu的時間, STATUS, B.SQL_TEXT 執行的sqlFROM V$SESSION ALEFT JOIN V$SQL B ON A.SQL_ADDRESS = B.ADDRESS AND A.SQL_HASH_VALUE = B.HASH_VALUEORDER BY b.cpu_time DESC
查出oracle當前的被鎖對象
SELECT l.session_id sid, s.serial#, l.locked_mode 鎖模式, l.oracle_username 登錄用戶, l.os_user_name 登錄機器用戶名, s.machine 機器名, s.terminal 終端用戶名, o.object_name 被鎖對象名, s.logon_time 登錄資料庫時間FROM v$locked_object l, all_objects o, v$session sWHERE l.object_id = o.object_id AND l.session_id = s.sidORDER BY sid, s.serial#;
kill掉當前的鎖對象可以為
alter system kill session 'sid， s.serial#『;
Ⅲ 用sql語句將查詢結果存入hashmap中後,怎樣寫一個servlet取出數據,並在jsp頁面顯示，最好寫出代碼，謝謝
把map存在request中，然後用EL表達式，迭代map:
<c:forEach var="item" items="${map2}">
${item.key} > ${item.value} <br>
</c:forEach>
上面的item.value應該就是Previous對象咯，你嘗試一下item.value.xxx看看能不能正常取值？
Ⅳ sql server 什麼時候用hash join
舉一個簡單的例子來說明SQL Server 中hash join的演算法.
例如有兩張表, 每張表都有10000行的記錄, 假設做join的兩個欄位都是從1到10000的序數.
如果要做hashjoin, 那麼首先對其中的一個表上的列進行hash運算, 將生成相同值的列放在一個桶里.
為了簡單起見, 假定這里的hash運算就是模100, 那麼這些行經過hash運算後, 會生成100組數據,也就是100個桶. 每個桶中都是100條除100後余數相同的記錄.
然後對另一個表中的join列做相同的hash運算, 根據得到的余數,放入對應的桶里.
於是得到的結果就是100個hash桶中, 每個桶中都有200條記錄, 分別來自兩個表.
然後在桶內,再做nested loop join, 這樣一個桶中最多做100*100次的比對, 100個桶最多做1,000,000次的比對.
而如果一開始就用nested loop join, 則最多需要做10000*10000次, 也就是100,000,000次. 兩種演算法就比對的次數來說,相差了100倍, 差異是很明顯的.
另外在多cpu的伺服器上, hashjoin可以並行的執行,而nestedloop join 通常只能串列的執行,這就使執行時間的差異更加明顯.
Ⅳ 如何sql的hash
這兩個hash_value 是資料庫內部使用的一個hash值 hash_value 具體可對應到 v$sql 的hash_value plan_hash_value 則對應到執行計劃相關表的hash值
Ⅵ oracle的SQL索引使用
1，第一次查詢慢，以後就快了，主要是因為第一次要進行磁碟操作，以後數據被cache到內存中了，不在操作磁碟，所以就快了。
2，對於你說的這四種查詢，where條件中的a=a估計你是舉例子這樣寫的吧。實際上應該是a=變數A。其他的b，c，d也是這樣。那麼這種語句都是可以利用你說的復合索引的。如果是RBO優化器，這四句都應該用索引。但是oracle現在推薦的CBO優化器不能保證你都走索引。
3，到底用沒用索引，你可以從v$sqlaera中找到你的語句對應的hash_value，然後從v$sql_plan中找到語句的執行計劃，通過執行計劃確認你的語句是不是使用了索引。
具體語句你可以類似如下寫法：
select
hash_value,sql_text
from
v$sqlarea
where
upper(sql_text)
like
'%你需要查找的sql語句的特徵片段%'
select
*
from
v$sql_plan
where
hash_value
=
上一句查到的hash_value