快捷導(dǎo)航

MYSQL神秘的HANDLER命令與實(shí)現(xiàn)方法

更新時(shí)間：2016年07月17日 00:19:18 投稿：mdxy-dxy

這篇文章主要介紹了MYSQL神秘的HANDLER命令與實(shí)現(xiàn)方法,需要的朋友可以參考下

MySQL“自古以來(lái)”都有一個(gè)神秘的HANDLER命令，而此命令非SQL標(biāo)準(zhǔn)語(yǔ)法，可以降低優(yōu)化器對(duì)于SQL語(yǔ)句的解析與優(yōu)化開(kāi)銷(xiāo)，從而提升查詢(xún)性能?？吹竭@里，可能有小伙伴不淡定了，這么好的東西為啥沒(méi)廣泛使用呢？這不是與幾年前很夯的handlersocket插件類(lèi)似嗎？

那么，我們先來(lái)看看Handler語(yǔ)法說(shuō)明：

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

首先從語(yǔ)法上看，HANDLER可以通過(guò)指定的索引去訪問(wèn)數(shù)據(jù)。但此語(yǔ)法并不支持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線程主鍵查詢(xún)跑到了近37W QPS，還是非常令人印象深刻的。對(duì)比SQL的SELECT查詢(xún)，整體測(cè)試結(jié)果如下圖所示：

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

復(fù)制代碼代碼如下:

Sql_cmd_handler_open::execute

Sql_cmd_handler_read::execute

Sql_cmd_handler_close::execute

ha_innobase::init_table_handle_for_HANDLER

ha_partition::init_table_handle_for_HANDLER()（7版本支持HANDLER操作分區(qū)表）

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

非一致性讀?。?？？
返回聚集索引中的所有列（即使是二級(jí)索引訪問(wèn)），而不能返回某個(gè)具體列
二級(jí)索引不使用LIMIT關(guān)鍵字，只能返回1行記錄
知道命令HANDLER的同學(xué)，可能會(huì)認(rèn)為HANDLER讀取存在臟讀問(wèn)題。因?yàn)镸ySQL官方文檔對(duì)于HANDLER讀取的說(shuō)明就是這么說(shuō)的：

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)確的說(shuō)法是可以允許提供不一致的讀取。但I(xiàn)nnoDB存儲(chǔ)引擎的HANDLER實(shí)現(xiàn)是支持一致性讀取的，Inside君親測(cè)的確不存在臟讀問(wèn)題。當(dāng)然，源碼說(shuō)明一切，可以發(fā)現(xiàn)在函數(shù)init_table_handle_for_HANDLER會(huì)對(duì)READVIEW進(jìn)行分配，而注釋也說(shuō)明了這點(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命令來(lái)做主鍵的查詢(xún)是不錯(cuò)的，減少了SQL解析器的開(kāi)銷(xiāo)，性能提升杠杠的。但為此，應(yīng)用要付出巨大的改動(dòng)，而SQL最大的優(yōu)勢(shì)就在于標(biāo)準(zhǔn)化。相信這也是目前NoSQL數(shù)據(jù)庫(kù)遇到的最大的一個(gè)問(wèn)題。比如MongoDB，Inside君每次寫(xiě)查詢(xún)時(shí)都要打開(kāi)官方的命令對(duì)照表……