資料庫引擎作為服務提供者

DBMS是個服務提供者，更精確的說，是服務提供者的集合。服務是對資料的操作，或讀取或更新，並且許多併發Session可能在同一時間請求服務。只用每個Session都高效執行時，DBMS才是高效的。

索引的有點：

假設表的鍵不是數值，而是字串。發現鍵同時包含大小寫，修改了查詢中的where子句，對鍵使用upper（）函式，從而喪失了使用索引的可能性。

當SQL語句提交的速度比服務速度要快時，系統性能就會出現嚴重問題；所有查詢都會受到影響，而不僅僅是慢慢查詢。

併發修改資料

修改資料操作越頻繁，維持良好效能的難度就越大。

鎖的粒度

加鎖的資料量小（細粒度鎖）則多個併發程序就可能同時修改同一表中的資料，而不會造成阻塞。不同程序之間可以有一定重疊，不一定非要等到一個程序執行的事務結束--從硬體角度看，這意味著處理器有更多工作要做，從而提高硬體資源利用效率。

加鎖處理

不要隨便使用表級鎖：當許多使用者正對同一個表執行一些短的更新事務時，我們不應該對同一個表的數百萬條几率進行更新的程式。

儘量縮短加鎖時間：必須所有事務都快，否則效能依然不佳，最差的一環決定鎖鏈的強度。

通過改寫where子句能加快select的執行，也能加快update和delete語句的執行。如果delete沒有where子句（ 級刪除整個表），使用truncate語句可能更合適，因為它清空表（或分割槽）更高效。

語句效能高，未必程式效能就高。在修改資料時，應考慮事務。達到數事務要求保留資料庫特定部分的鎖，所以不需要再事務中完成的工作，尤其是耗時的活動，應該排除在事務之外。

在事務內應該：

儘可能避免SQL語句上的迴圈處理。

無論是以應用程式伺服器或客戶端執行，應儘量減少程式和資料庫之間的互動次數，因為這增加了網路訪問的開銷。

重分利用DBMS提供的機制，使跨機器互動的次數降至最少（例如，運用儲存程式或資料讀取）。

把所有不重要的、不必須的SQL語句放在邏輯工作單元之外。如果遇到錯誤，就應該先以rollback結束事務，然後在查詢錯誤資訊表，因為先結束事務會提早釋放鎖，有助於提高吞吐量。

oracle的使用者可以用insert和update語句的returning。。。into。。子句返回由系統產生的值，這避免了額外增加一次對伺服器的呼叫。

加鎖與提交

對於批處理程式，併發控制不是問題，所以避免頻繁提交。延遲提交會延長加鎖時間，且系統要為undo操作記錄更多改變前資料映像，這會消耗不少資源。如果處理因某種原因失敗了，回滾也要花更長時間。

加鎖與可伸縮性

與表級鎖相比，行級鎖能產生更佳的吞吐量。

資源競爭

插入與競爭：競爭會發生在兩個地方：表和索引。

DBA解決方案：

事務控制元件：表或索引由物理塊組成，每個物理塊中為事務條目預留了空間。DBA的第一個手段就是調整事務條目所佔空間的大小。事務條目的甄工是資源衝突的重要原因。

可用列表：可以讓insert操作分散到不同的物理塊，有事可以藉助儲存管理擁有的能力做到這一點。

架構解決方案：