測試環境
- 資料量：212,992 筆
- MySQL 版本：5.0
- 硬體：同一台機器
- 操作：批次 UPDATE
測試一：存儲過程效能提升驗證
測試邏輯
同樣的批次更新邏輯，分別用存儲過程與客戶端循環發送 SQL執行 5 次取平均。
實測數據
| 輪次 | 存儲過程 | 直寫 SQL | 提升幅度 |
|---|
| 1 |
10,985 ms |
14,906 ms |
26.3% |
| 2 |
11,562 ms |
14,828 ms |
22.0% |
| 3 |
11,890 ms |
14,500 ms |
18.0% |
| 4 |
11,360 ms |
15,047 ms |
24.5% |
| 5 |
12,407 ms |
14,578 ms |
14.9% |
結論：存儲過程在大批量資料處理上穩定提升 15~26% 效能，主要優勢：
- 減少網路往返（客戶端→伺服器）開銷。
- 伺服器端編譯優化，避免重複解析。
- 批次操作原子化，減少交互協議開銷。
反駁觀點：「存儲過程無效能優勢」為錯誤認知，實測證明在高批次寫入場景有明顯優勢。
測試二：LIMIT 分頁優化驗證
測試場景 A：淺分頁
-- 原始
LIMIT 10, 10
-- 優化
WHERE id >= (SELECT id FROM t ORDER BY id LIMIT 10, 1) LIMIT 10
| 輪次 | 原始 | 優化 |
|---|
| 1 |
10 ms |
15 ms |
| 2 |
10 ms |
15 ms |
| 3 |
10 ms |
15 ms |
結論：淺分頁原始 LIMIT 更優（子查詢額外開銷大於掃描收益）。
測試場景 B：深分頁
-- 原始
LIMIT 100000, 10
-- 優化
WHERE id >= (SELECT id FROM t ORDER BY id LIMIT 100000, 1) LIMIT 10
| 輪次 | 原始 | 優化 | 提升 |
|---|
| 1 |
78 ms |
46 ms |
41% |
| 2 |
78 ms |
47 ms |
40% |
| 3 |
78 ms |
47 ms |
40% |
測試場景 C：極深分頁
LIMIT 200000, 10
| 輪次 | 原始 | 優化 | 提升 |
|---|
| 1 |
156 ms |
79 ms |
49% |
| 2 |
188 ms |
78 ms |
59% |
| 3 |
153 ms |
78 ms |
49% |
| 4 |
141 ms |
94 ms |
33% |
| 5 |
141 ms |
93 ms |
34% |
測試場景 D：大頁面深分頁
LIMIT 200000, 10000
| 輪次 | 原始 | 優化 | 提升 |
|---|
| 1 |
171 ms |
94 ms |
45% |
| 2 |
140 ms |
78 ms |
44% |
| 3 |
172 ms |
93 ms |
46% |
| 4 |
156 ms |
93 ms |
40% |
| 5 |
157 ms |
94 ms |
40% |
綜合結論與建議
- 存儲過程：大批量寫入/複雜邏輯封裝場景推薦使用，效能穩定提升 15%+。
- LIMIT 優化：
- Offset < 1000：直接用
LIMIT。
- Offset ≥ 10000：必須優化，子查詢定位 ID 可節省 40~60% 時間。
- 極大 Offset + 大 Limit：優化效果更明顯。
- 游標分頁（記住上頁最大 ID）為終極方案，效能與 Offset 無關，強烈建議前端採用「載入更多」模式。
