HANDLER Statement To employ the  HANDLER  interface to refer to a table’s  PRIMARY KEY , use the quoted identifier ‘PRIMARY‘ : The second  HANDLER ... READ  syntax fetches a row from the table in index order that matches the WHERE  condition. The third  HANDLER ... READ  syntax fetches a row from the table in natural row order that matches the WHERE  condition. It is faster than  HANDLER  tbl_name  READ  index_name  when a full table scan is desired. Natural row order is the order in which rows are stored in a  MyISAM  table data file. This statement works for  InnoDB  tables as well, but there is no such concept because there is no separate data file. Without a  LIMIT  clause, all forms of  HANDLER ... READ  fetch a single row if one is available. To return a specific number of rows, include a  LIMIT  clause. It has the same syntax as for the  SELECT  statement. See Section 13.2.10, “SELECT Statement” . HANDLER ... CLOSE  closes a table that was opened with  HANDLER ... OPEN . HANDLER  tbl_name  READ ‘PRIMARY‘ ... There are several reasons to use the  HANDLER  interface instead of normal  SELECT  statements: • HANDLER  is faster than  SELECT : •A designated storage engine handler object is allocated for the  HANDLER ... OPEN . The object is reused for subsequent  HANDLER  statements for that table; it need not be reinitialized for each one. •There is less parsing involved. •There is no optimizer or query-checking overhead. •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. • HANDLER  makes it easier to port to MySQL applications that use a low-level  ISAM -like interface. (See Section 15.20, “InnoDB memcached Plugin”  for an alternative way to adapt applications that use the key- value store paradigm.) • HANDLER  enables you to traverse a database in a manner that is difficult (or even impossible) to accomplish with  SELECT . The  HANDLER  interface is a more natural way to look at data when working with applications that provide an interactive user interface to the database. HANDLER  is a somewhat low-level statement. For example, it does not provide consistency. That is, HANDLER ... OPEN  does  not  take a snapshot of the table, and does  not  lock the table. This means that after a  HANDLER ... OPEN  statement is issued, table data can be modified (by the current session or other sessions) and these modifications might be only partially visible to  HANDLER ... NEXT  or HANDLER ... PREV  scans. An open handler can be closed and marked for reopen, in which case the handler loses its position in the table. This occurs when both of the following circumstances are true: If a table is flushed with  FLUSH TABLES  tbl_name  WITH READ LOCK  was opened with  HANDLER , the handler is implicitly flushed and loses its position. TRUNCATE TABLE  for a table closes all handlers for the table that were opened with  HANDLER OPEN . •Any session executes  FLUSH TABLES  or DDL statements on the handler’s table. •The session in which the handler is open executes non- HANDLER  statements that use tables. 2627