我們是不是忘了真實世界存在的樣子？

Facebook 工程師，同時也是 MySQL 資料庫專家的 Mark Callaghan 表示，從 MySQL 5.6 到 5.7 乃至接下來的 8.0，都可以看到很多評比數據指出高併發工作 (high-concurrency workloads) 的效能表現愈來愈好。但一般人可能沒有注意到，低併發工作 (low-concurrency workloads) 的表現則是愈來愈差。

例如，MySQL 5.7 及 MySQL 8.0 的低併發工作表現只有 MySQL 5.6 的 60% ~ 70% (效能少了約三分之一)。

他呼籲除了不要忘了低併發工作表現外，也始終都致力發布並修補 MySQL 低併發工作的問題。雖然確實成功修補了很多，但 MySQL 整團開發團隊在效能比重上，仍然比較在意高併發上。

Peter Zaitsev，Percona (MySQL 知名顧問公司) 的共同創辦人兼 CEO 在 2013 年也寫過類似的言論。

他指出低併發工作的表現也是很重要的。

  1. 有些業務情境非常重視 Response time，而併發數 1 通常都是最佳表現。若只追求高併發，會失去這個重要的市場。
  2. 很多情境都是單執行緒 (single-thread execution)，例如很多批次工作 (batch jobs) 都是單執行緒；過去 MySQL Replication 也是單執行緒，雖然 MySQL 5.6 開始支援多執行緒，但在某些情況下，還是以單執行緒執行。
  3. 很多資料庫的維護操作都是單執行緒的，例如 “ALTER TABLE”。

所以，他認為，事實上大多數的時候，系統都是在低併發工作情境下運作。過度專注高併發工作表現，很容易在面對實際情況時誤判。例如，高併發表現明明就很好，為什麼系統上線時總是不理想？因為你忘了，系統實際面對的根本不是高併發，而是低併發的狀況。

總結，

  1. 軟體功能要求愈多，通常效能會愈來愈差。若效能只專注在高併發時，更可能犧牲的是低併發表現。
  2. 如果業務場景重視 Response time，或是非多核環境，一味把軟體升級到最新版，結果可能並非我們所想像的。
  3. 這不只是 MySQL 的問題，想想我們手中所依賴的各種軟體，開發者是不是有真正考慮到這個問題。至少 MySQL 團隊有人在意也專注解決。