参数解读
各参数含义参考这个连接（摘抄如下）：MySQL Handler
mysql> show global status like 'Handle%';
+----------------------------+---------------+
| Variable_name | Value |
+----------------------------+---------------+
| Handler_commit | 292547310 |
| Handler_delete | 20004688 |
| Handler_discover | 0 |
| Handler_external_lock | 298778503 |
| Handler_mrr_init | 0 |
| Handler_prepare | 89764296 |
| Handler_read_first | 84936796 |
| Handler_read_key | 197690980 |
| Handler_read_last | 25 |
| Handler_read_next | 449603395282 |
| Handler_read_prev | 488140 |
| Handler_read_rnd | 17904308 |
| Handler_read_rnd_next | 2234678057572 |
| Handler_rollback | 3965287 |
| Handler_savepoint | 2 |
| Handler_savepoint_rollback | 566 |
| Handler_update | 150669454 |
| Handler_write | 1392716731 |
+----------------------------+---------------+
18 rows in set (0.00 sec)
| Handler_commit | 内部提交语句数
| Handler_delete | 请求从表中删除行的次数。
| Handler_discover | MySQL服务器可以问NDB CLUSTER存储引擎是否知道某一名字的表。这被称作发现。Handler_discover说明通过该方法发现的次数。
| Handler_external_lock | 此变量与锁定操作数量有关，主要是在表访问的开始和结束时起作用。
| Handler_mrr_init | 服务器使用存储引擎自己实现的多范围读取的次数。
| Handler_prepare | 用于两阶段提交操作的准备阶段的计数器。
| Handler_read_first | 索引中第一条被读的次数。如果较高，它建议服务器正执行大量全索引扫描；例如，SELECT col1 FROM foo，假定col1有索引。
| Handler_read_key | 根据键读一行的请求数。如果较高，说明查询和表的索引正确。
| Handler_read_last | 根据键读最后一行的请求数。
| Handler_read_next | 按照键顺序读下一行的请求数。如果你用范围约束或如果执行索引扫描来查询索引列，该值增加。
| Handler_read_prev | 按照键顺序读前一行的请求数。该读方法主要用于优化ORDER BY … DESC。
| Handler_read_rnd | 根据固定位置读一行的请求数。如果你正执行大量查询并需要对结果进行排序该值较高。你可能使用了大量需要MySQL扫描整个表的查询或你的连接没有正确使用索引。
| Handler_read_rnd_next | 在数据文件中读下一行的请求数。如果你正进行大量的表扫描，该值较高。通常说明你的表索引不正确或写入的查询没有利用索引。
| Handler_rollback | 内部ROLLBACK语句的数量
| Handler_savepoint | 在一个存储引擎放置一个保存点的请求数量。
| Handler_savepoint_rollback | 在一个存储引擎的要求回滚到一个保存点数目。
| Handler_update | 请求更新表中一行的次数。
| Handler_write | 请求向表中插入一行的次数。
Handler_read_rnd_next的值高则意味着查询运行低效，并且应该建立索引补救或优化。这个值的含义是在数据文件中读取下一行的请求数。如果正在进行大量的表扫描，Handler_read_rnd_next的值比较高通常说明表索引不正确或写入的查询没有有效利用索引。
实际优化中比较看重的几个参数
Handler_read_first和Handler_read_rnd_next
如果前者值较大，说明可能是一个全索引扫描，此外走全表也可能导致这个值比较大；后者值较大，说明扫描的行非常多，可能没有合理的使用索引
Handler_read_key
如果这个值比较大，说明索引使用良好
案例
SELECT CASE WHEN O.FD_ORDER_BUS_TYPE = 1 THEN '自营' ELSE '他营' END AS FD_ORDER_BUS_TYPE, S.SUPPLIER_NAME, G.GOODS_CODE, G.GOODS_NAME, D.FD_NUM
, D.FD_UNIT_NAME, CASE WHEN D.FD_IS_GIFT = '1' THEN '是' ELSE '否' END AS FD_IS_GIFT, (
SELECT dic.dic_name
FROM plat_system_dictionary dic
WHERE dic.DIC_VALUE = D.FD_GIFT_TYPE
AND dic.DIC_DICTYPE_CODE = 'giftType'
) AS FD_GIFT_TYPE_NAME, D.FD_UNIT_PRICE, D.FD_TOTAL_PRICE
, O.FD_ID, O.FD_NO, C.fd_code, C.fd_name, DATE_FORMAT(O.FD_ORDER_DATE, '%Y-%m-%d') AS FD_ORDER_DATE
, (
SELECT CR.fd_code
FROM plat_shop_customer_info CR
WHERE CR.fd_id = O.FD_REC_ORG_ID
) AS FD_REC_ORG_CODE, O.FD_REC_ORG_NAME, (
SELECT CB.fd_code
FROM plat_shop_customer_info CB
WHERE CB.fd_id = O.FD_BILL_ORG_ID
) AS FD_BILL_ORG_CODE, O.FD_BILL_ORG_NAME, CASE WHEN O.FD_IS_TRAN_DIRECT = '1' THEN '是' ELSE '否' END AS FD_IS_TRAN_DIRECT
, CASE WHEN O.FD_IS_ALL_BILL = '1' THEN '是' ELSE '否' END AS FD_IS_ALL_BILL, (
SELECT dic.dic_name
FROM plat_system_dictionary dic
WHERE dic.DIC_VALUE = O.FD_ORDER_STATUS
AND dic.DIC_DICTYPE_CODE = 'orderStatus'
) AS FD_ORDER_STATUS_NAME, O.NC_ORDER_CODE, a.AREATYPE_NAME, U.SYSUSER_NAME AS CREATE_USER_NAME
, substring_index(O.FD_CONTACTS_INFO, ':', 1) AS FD_LINKMAN, substring_index(O.FD_CONTACTS_INFO, ':', -1) AS FD_MOBILE_NUMBER, O.FD_REC_ADDR AS FD_ADDRESS, D.FD_DESC
FROM plat_shop_order_detail D
LEFT JOIN plat_shop_order O ON O.FD_ID = d.FD_ORDER_ID
LEFT JOIN plat_shop_customer_info C ON o.FD_ORDER_ORG_ID = C.fd_id
LEFT JOIN plat_shop_areatype a ON o.FD_AREATYPE_ID = a.AREATYPE_ID
LEFT JOIN plat_shop_goods G ON G.GOODS_ID = D.FD_GOODS_ID
LEFT JOIN plat_shop_supplier S ON G.GOODS_SUPPLIER_ID = S.SUPPLIER_ID
LEFT JOIN plat_system_sysuser U ON U.SYSUSER_ID = O.FD_CREATE_USER_ID
LEFT JOIN plat_system_sysuser U1 ON U1.SYSUSER_ID = O.FD_PLAT_AUDIT_USER_ID
WHERE 1 = 1
AND O.FD_BILL_TYPE = '1'
AND O.FD_BILL_TYPE = '1'
AND O.FD_ORDER_BUS_TYPE = '2'
AND O.FD_ORDER_STATUS = '3'
ORDER BY O.FD_NO DESC;
几张表的数据量都很小，均是不到1W行的水平，然而执行时间接近2s，查看执行计划，可以发现O表和dic表都走的全表，但行数都不算太大，一个4000+，一个1000+
其中O表的using filesort显得比较扎眼，初步判断执行慢是因为排序造成的
对O表添加联合索引，发现需要添加的字段还挺多，而且这些字段的选择性都奇差无比；索引添加完成后，执行时间几乎没有缩短，说明这个filesort并不是查询慢的根本原因。查看handler状态
1.flush status;
2.执行语句
3.show status like '%handler_read%';
可以看到Handler_read_rnd_next高达400W，前面添加的索引几乎没起作用
对gic表添加索引后，Handler_read_rnd_next值下降到6000，执行时间下降为原来的1/10
O表的索引删除后，Handler_read_rnd_next值无变化，执行时间无变化，考虑到O表较小，而且索引列的选择性都奇差无比，这个索引实在是没有存在的必要，故删除该索引
最终的执行计划如下
