Mysql
MySQL 中的連結表與儲存過程的性能對比
假設我有一個子表單，在數據表視圖中用於多條記錄，它使使用者可以完全 CRUD 控制特定的 MySQL 表。（記錄由父表單過濾）。
選項 1 是簡單地創建一個連結表並將其設置為子表單的記錄源。這當然需要很少的工作。
選項 2 是創建一組儲存過程，用於從 MySQL 表向/從本地臨時表插入、刪除、更新和讀取記錄。然後將子表單的記錄源設置為本地表，並將適當的表單事件綁定到適當的儲存過程呼叫。顯然，這比選項 1 需要更多的工作。
現在顯而易見的問題是為什麼要選擇選項 2？好吧，我一直在嘗試用儲存過程替換連結表，並發現速度提高相當可觀，尤其是在慢速網路上。我也做了一些偵探工作，並在 MySQL 日誌文件中進行了探勘，我注意到連結表方法會產生數量驚人的 SQL 呼叫。這解釋了我認為的性能差異。
無論如何，我現在正在考慮用儲存過程選項替換所有連結表（也許只是重要的表）。有沒有其他人有這種經驗？有什麼想法或建議嗎？
當我使用 Access 時，我將這兩種技術用作某種形式的命令查詢分離(CQS)
也就是說，表單可以讀取基表，但所有寫入都是通過儲存過程進行的。
就我而言，我選擇了這個
- 安全/審計原因
- 更容易處理數據完整性
- 為其他客戶重用編寫程式碼
注意：為了某些安全性，我使用 Access 的視圖而不是基表。
為清楚起見，在評論後編輯：
“只讀”是指對 Access 透明的伺服器端權限。如果我們允許，Access 會嘗試寫入（而不是攔截呼叫並呼叫儲存過程），並且我們會從數據庫引擎中得到一個錯誤。