ＣＪ軟體工程日誌

 如題，近期因為寫 Store Procedure 產生了一個錯誤 /*EXECUTE 之後的交易計數顯示遺漏了 COMMIT 或 ROLLBACK TRANSACTION 陳述式。前次計數 = 0，目前的計數 = 1。*/ 後續就發現特定 Table 無法搜尋，直覺就是應該被 Lock 住了，但是沒有特別處理過這問題，這次特別紀錄下。 以下開始 DB LOCK 的說明及解釋:      1.     模擬 Db Lock，只要有開啟 Transactoin 但是沒有 Commit 或 Rollback 就會產生 Dead Lock。               以下使用 北風資料庫為範例: BEGIN TRAN UPDATE dbo.Employees SET Country = 'JAPAN'      2.       此時 dbo.Employees 已經被 Lock 住了，可以用以下 SQL 查詢 SELECT request_session_id AS spid, resource_type AS rt, resource_databASe_id AS rdb, (CASE resource_type WHEN 'OBJECT' then object_name(resource_ASsociated_entity_id) WHEN 'DATABASE' then ' ' ELSE (SELECT object_name(object_id) FROM sys.partitions WHERE hobt_id = resource_ASsociated_entity_id) END) AS objname, resource_description AS rd, request_mode AS rm, request_status AS rs FROM sys.dm_tran_lock...

 如題，把一些工作上遇到的SQL效能問題記錄下來: 1.     盡量不要在 WHERE 條件中，把Table的欄位進行 Convert , Cast ... 轉換處理！     原因: 此動作會造成 Table 中每筆資料都會轉置，當資料量大時，會造成效能瓶頸。     解決辦法: 將 WHERE 要比較的參數進行轉換，而不是對 Table 的參數進行轉換，甚至可以先在方 DECLARE 一個變數先轉換好，在放到 SQL 語句中。 2.     IN、JOIN、EXISTS 如何選擇:     2.1     盡量不要在 IN 中處理子查詢、CTE！          原因:   因為每次 IN 都會重新查一次子查詢、 CTE，資料量大時，效能極差          解決辦法:  將 子查詢 以 CTE 方式處理，之後再 JOIN 或 EXISTS     2.2    面臨  子查詢、CTE， JOIN 或 EXISTS 兩種取捨！           解決思路:                                    a.     理論上 效能優劣: EXISTS  >  JOIN，因為一旦 EXISTS 尋找找到特定內容，查詢執行就會停止，而 JOIN 將一直持續到最後。           ...