MySQL“自古以來”都有一個神秘的HANDLER命令，而此命令非SQL標準語法，可以降低優化器對于SQL語句的解析與優化開銷，從而提升查詢性能。看到這里，可能有小伙伴不淡定了，這么好的東西為啥沒廣泛使用呢？這不是與幾年前很夯的handlersocket插件類似嗎？

那么，我們先來看看Handler語法說明：

HANDLER tbl_name OPEN [ [AS] alias]
HANDLER tbl_name READ index_name { = | <= | >= | < | > } (value1,value2,…) [ WHERE where_condition ] [LIMIT … ]
HANDLER tbl_name READ index_name { FIRST | NEXT | PREV | LAST } [ WHERE where_condition ] [LIMIT … ]
HANDLER tbl_name READ { FIRST | NEXT } [ WHERE where_condition ] [LIMIT … ]
HANDLER tbl_name CLOSE

首先從語法上看，HANDLER可以通過指定的索引去訪問數據。但此語法并不支持DML操作。此外，由于減少了SQL解析，Handler命令的性能真的非常不錯，根據Inside君的簡單主鍵測試，Handler命令比SQL要快40%~45%。測試腳本如下：

SET @id=FLOOR(RAND()*1000000);HANDLER sbtest.sbtest1 OPEN AS c;HANDLER C READ `PRIMARY` = (@id);HANDLER C CLOSE;

在Inside君的24C的測試服務器上，64線程主鍵查詢跑到了近37W QPS，還是非常令人印象深刻的。對比SQL的SELECT查詢，整體測試結果如下圖所示：

命令HANDLER的主要實現在源碼sql_handler.h、sql_handler.cc，設個斷點就能觀察到具體的流程。MySQL上層及InnoDB存儲引擎層主要實現函數入口為：

既然性能不錯，為什么在生產環境中并不見到命令HANDLER的使用呢？主要是因為HANDLER命令存在以下幾個主要問題：

非一致性讀取？？？
返回聚集索引中的所有列（即使是二級索引訪問），而不能返回某個具體列
二級索引不使用LIMIT關鍵字，只能返回1行記錄
知道命令HANDLER的同學，可能會認為HANDLER讀取存在臟讀問題。因為MySQL官方文檔對于HANDLER讀取的說明就是這么說的：

The handler interface does not have to provide a consistent look of the data (for example, dirty reads are permitted), so the storage engine can use optimizations that SELECT does not normally permit.
然而需要特別注意的是，MySQL文檔中準確的說法是可以允許提供不一致的讀取。但InnoDB存儲引擎的HANDLER實現是支持一致性讀取的，Inside君親測的確不存在臟讀問題。當然，源碼說明一切，可以發現在函數init_table_handle_for_HANDLER會對READVIEW進行分配，而注釋也說明了這點：

/* We let HANDLER always to do the reads as consistent reads, even
if the trx isolation level would have been specified as SERIALIZABLE */
m_prebuilt->select_lock_type = LOCK_NONE;
m_prebuilt->stored_select_lock_type = LOCK_NONE;

貌似用HANDLER命令來做主鍵的查詢是不錯的，減少了SQL解析器的開銷，性能提升杠杠的。但為此，應用要付出巨大的改動，而SQL最大的優勢就在于標準化。相信這也是目前NoSQL數據庫遇到的最大的一個問題。比如MongoDB，Inside君每次寫查詢時都要打開官方的命令對照表……