技術演進迅猛，許多源於早期版本或商業競爭的「鐵律」早已過時。本文針對六大高頻誤區，結合 MySQL 5.6/5.7/8.0 及 MariaDB、InnoSQL 等分支實踐，給出基於當前版本的權威澄清。
澄清：該結論約源於 2005 年論壇討論，僅反映堆表與索引組織表在更新機制上的差異。截至 MySQL 5.6/5.7，InnoDB 在 讀寫混合、事務、崩潰恢復、MVCC、行鎖、外鍵、自適應哈希索引、Change Buffer、雙重寫** 等全維度完勝 MyISAM。MyISAM 已停止開發，除極少數唯讀分析場景外，無任何理由選擇 MyISAM。
澄清：並發優化一直是官方重點。MySQL 5.7 單實例只讀 QPS 輕松突破 50 萬。關鍵優化包括：
若遇上層業務並發瓶頸（如秒殺），可引入線程池（Thread Pool）或 ProxySQL 連接複用解決，非引擎本身瓶頸。
澄清：5.6 前確存在單線程復制、無校驗和、主庫崩潰從庫不一致等問題。5.6 引入 GTID、Binlog 校驗和、從庫並行復制（基於庫）、Crash-safe Slave（relay-log.info 存表），徹底解決可靠性。現網故障 99% 為配置不當（如未開 sync_binlog=1、relay_log_purge=0）。
澄清：邏輯復制（Binlog）確實有解析開銷，但 5.7/MariaDB 10.0+ 引入 並行復制（基於組提交/WriteSet），網易電商實測延遲從 5 小時降為 0。物理復制（如 Oracle Data Guard）亦有網絡帶鋪、日志傳輸延遲。綜合看，並行邏輯復制已滿足絕多數業務 RPO=0、RTO<分钟 需求。
澄清：MySQL 5.7 引入 半同步復制增強（rpl_semi_sync_master_wait_point=AFTER_SYNC），配合 sync_binlog=1、innodb_flush_log_at_trx_commit=1，實現 零數據丟失。InnoSQL 5.5 即支援，網易雲數據庫生產驗證超 3 年。PostgreSQL、Oracle 同樣依賴遠端日志確認機制，非 MySQL 獨有短板。
澄清：5.6 前存在「組提交失效」Bug，設 0/2 可繞過但引入數據風險。5.6/InnoSQL 5.5/MariaDB 5.5 已修復組提交，生產環境必須設 sync_binlog=1。性能損耗可通過 Battery-backed RAID 卡、NVMe SSD、調大 innodb_flush_log_at_timeout 緩解。
| 版本 | 關鍵突破 |
|---|---|
| 5.5 | InnoDB 成為默認引擎、多 Buffer Pool、自適應哈希索引 |
| 5.6 | GTID、Crash-safe Slave、InnoDB 全文索引、Online DDL |
| 5.7 | 並行復制、半同步增強、JSON、Sys Schema、Query Rewrite |
| 8.0 | CSE、窗口函數、CTE、資源組、即時 DDL、雙向復制 |
以發展眼光看待技術棧，定期複盤官方 Release Notes 及社區最佳實踐，才能避免「以偏概全」導致架構選型失誤。
