MySQL“自古以來”都有一個(gè)神秘的HANDLER命令，而此命令非SQL標(biāo)準(zhǔn)語法，可以降低優(yōu)化器對(duì)于SQL語句的解析與優(yōu)化開銷，從而提升查詢性能?？吹竭@里，可能有小伙伴不淡定了，這么好的東西為啥沒廣泛使用呢？這不是與幾年前很夯的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可以通過指定的索引去訪問數(shù)據(jù)。但此語法并不支持DML操作。此外，由于減少了SQL解析，Handler命令的性能真的非常不錯(cuò)，根據(jù)Inside君的簡(jiǎn)單主鍵測(cè)試，Handler命令比SQL要快40%~45%。測(cè)試腳本如下：

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

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

命令HANDLER的主要實(shí)現(xiàn)在源碼sql_handler.h、sql_handler.cc，設(shè)個(gè)斷點(diǎn)就能觀察到具體的流程。MySQL上層及InnoDB存儲(chǔ)引擎層主要實(shí)現(xiàn)函數(shù)入口為：

既然性能不錯(cuò)，為什么在生產(chǎn)環(huán)境中并不見到命令HANDLER的使用呢？主要是因?yàn)镠ANDLER命令存在以下幾個(gè)主要問題：

非一致性讀取？？？
返回聚集索引中的所有列（即使是二級(jí)索引訪問），而不能返回某個(gè)具體列
二級(jí)索引不使用LIMIT關(guān)鍵字，只能返回1行記錄
知道命令HANDLER的同學(xué)，可能會(huì)認(rèn)為HANDLER讀取存在臟讀問題。因?yàn)镸ySQL官方文檔對(duì)于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文檔中準(zhǔn)確的說法是可以允許提供不一致的讀取。但I(xiàn)nnoDB存儲(chǔ)引擎的HANDLER實(shí)現(xiàn)是支持一致性讀取的，Inside君親測(cè)的確不存在臟讀問題。當(dāng)然，源碼說明一切，可以發(fā)現(xiàn)在函數(shù)init_table_handle_for_HANDLER會(huì)對(duì)READVIEW進(jìn)行分配，而注釋也說明了這點(diǎn)：

/* 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命令來做主鍵的查詢是不錯(cuò)的，減少了SQL解析器的開銷，性能提升杠杠的。但為此，應(yīng)用要付出巨大的改動(dòng)，而SQL最大的優(yōu)勢(shì)就在于標(biāo)準(zhǔn)化。相信這也是目前NoSQL數(shù)據(jù)庫遇到的最大的一個(gè)問題。比如MongoDB，Inside君每次寫查詢時(shí)都要打開官方的命令對(duì)照表……