sql server中不少怪異問題都是由用錯關聯方式引起的，從2000到2005有所改善，但2005的查詢優化引擎還是存在「犯傻」的時候
1. 問題1
現象：乙個儲存過程，通過乙個服務程式呼叫，長時間不能結束，資料庫伺服器顯示該儲存過程執行到某個語句時一直等待在那，資料庫伺服器記憶體充足，cpu消耗幾乎沒有。把這個儲存過程拿出來直接在查詢分析器中執行，引數跟程式呼叫時完全類似，立即結束且結果正確
解決方案：排除了阻塞等原因，因為放在查詢分析器中執行時一切正常，從執行計畫等方面無法看出任何問題，也排除了磁碟io等方面的原因，實在想不到其他的了。最後懷疑是sql server查詢引擎join方式選的不對，強制使用hash join後，程式呼叫恢復正常
疑點：一直沒有發現程式呼叫與直接使用查詢分析器執行，這2者之間存在哪些差別，會影響到sql server查詢優化決策
2. 問題2
現象：乙個不算複雜的查詢，用到了row_number函式分頁，一執行就會導致伺服器8個cpu全部100%，很長時間（好幾分鐘）不能結束。使用臨時表實現同樣的效果，幾秒鐘完成
語句1：
select
row_number() over(order by columnname1 asc) as fc_rownumber
,count(1) over() as fc_count
,* from (
select 產品 as columnname1,產品描述 as columnname2,入庫日期 as columnname7,預期數量 as columnname8
,入庫數量 as columnname9,行狀態 as columnname10,**商 as columnname11,**商名稱 as columnname12
from v_收貨明細查詢
where 入庫日期 >= '2010-7-1'
) tt_mainkey_tmp
執行計畫：
語句2：
select * from (
select
row_number() over(order by columnname1 asc) as fc_rownumber
,count(1) over() as fc_count
,* from (
select 產品 as columnname1,產品描述 as columnname2,入庫日期 as columnname7,預期數量 as columnname8
,入庫數量 as columnname9,行狀態 as columnname10,**商 as columnname11,**商名稱 as columnname12
from v_收貨明細查詢
where 入庫日期 >= '2010-7-1'
) tt_mainkey_tmp
) tt_ret_tmp
where fc_rownumber between 1 and 1000
order by columnname1 asc
執行計畫：
僅僅是把sql作為乙個子查詢，在外面多包裝了一下，整個查詢計畫就不一樣了。排除了統計資訊不準確、索引碎片等狀況
2個查詢計畫中對3個表使用的都是聚集索引掃瞄，基本上就是關聯演算法不一樣
因為用的並行查詢，三個表資料都有幾十萬和一百多萬，巢狀迴圈需要執行幾十萬次，所以單個查詢導致所有cpu都100%。估計高cpu是由於lazy spool操作造成的
解決方案：
強制用hash join，或者加索引避免sql server出錯，或者用臨時表繞過去
elasticsearch關聯方式簡介
一 應用層連線 多索引，但是沒有資料顯示多個索引之間應該怎樣關聯，只能粗暴的當成乙個文件 params index type body json 二 非規範化資料 冗餘 將其他文件的資料統計出來，再根據關聯字段，將統計結果更新到本資料 問題 資料量大時，的的foreach一條一條更新，速度慢 三 巢...
oracle表之間的關聯方式
oracle表之間的關聯方式多表之間的連線有三種方式 nestedloops，hash join 和 sort merge join.一 nested loop 對於被連線的資料子集較小的情況，巢狀迴圈連線是個較好的選擇。在巢狀迴圈中，內錶被外表驅動，外表返回的每一行都要在內表中檢索找到與它匹配的行...
UML中的關聯方式的區分
對於類之間的關聯性的關係中，依賴，關聯，聚合，以及組合 這四種關聯關係有時不是很能區分開來，特別是依賴，關聯，聚合這三種 組合因為是最強耦合的關聯關係，其實還是相對好辨別的 在此從網上找乙個摘抄，記下來 組合表示 contains a關係，是一種強烈的包含關係。組合類負責被組合類的生命週期 兩者生命...