mysql索引無效且sending data耗時巨大原因分析

　　一朋友最近新上線一個項目，本地測試環境跑得好好的，部署到線上卻慢得像蝸牛一樣。后來查詢了一下發現一個sql執行了16秒，有些長的甚至80秒。本地運行都是毫秒級別的查詢。下面記錄一下困擾了兩天的，其中一條sql的優化。

　　表結構及現象描述：

CREATE TABLE `wp_goods` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `user_openid` varchar(255) NOT NULL DEFAULT '',
  `description` longtext ,
  `upset_price` decimal(10,2) DEFAULT NULL ,
  `reference_price` decimal(10,2) DEFAULT NULL ,
  `offer_unit` decimal(10,2) DEFAULT NULL ,
  `end_time` int(11) DEFAULT NULL ,
  `type` tinyint(4) DEFAULT NULL ,
  `is_bail` tinyint(4) DEFAULT NULL ,
  `is_express` tinyint(4) DEFAULT NULL ,
  `is_return` tinyint(4) DEFAULT NULL ,
  `createtime` int(11) DEFAULT NULL ,
  `is_sell` tinyint(4) DEFAULT NULL ,
  `is_draft` tinyint(1) NOT NULL DEFAULT '1' ,
  `scan_count` int(11) NOT NULL ,
  `title` varchar(255) NOT NULL ,
  `is_trash` tinyint(1) NOT NULL DEFAULT '1' ,
  `countdown` smallint(6) NOT NULL DEFAULT '0' ,
  `bail_money` tinyint(4) NOT NULL DEFAULT '0' ,
  `cat_id` tinyint(4) NOT NULL,
  `sort` int(10) unsigned NOT NULL DEFAULT '1' ,
  PRIMARY KEY (`id`),
  KEY `cat_id` (`cat_id`),
  KEY `index_id_user_openid` (`id`,`user_openid`) USING BTREE,
  KEY `index_user_openid` (`user_openid`) USING BTREE,
  KEY `index_id` (`id`) USING BTREE
) ENGINE=MyISAM AUTO_INCREMENT=10094 DEFAULT CHARSET=utf8;

CREATE TABLE `sys_users` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `openid` varchar(50) DEFAULT NULL,
  `nickname` varchar(20) DEFAULT NULL,
  `sex` char(255) DEFAULT NULL,
  `phone` varchar(11) DEFAULT NULL,
  `country` varchar(10) DEFAULT NULL,
  `province` varchar(10) DEFAULT NULL,
  `city` varchar(10) DEFAULT NULL,
  `headimgurl` varchar(200) DEFAULT NULL,
  `createtime` varchar(20) DEFAULT NULL,
  `is_subject` tinyint(4) NOT NULL DEFAULT '1' ,
  `black` tinyint(4) NOT NULL DEFAULT '1' ,
  `wd_sort` smallint(5) unsigned DEFAULT '1000' ,
  `wp_sort` smallint(5) unsigned NOT NULL DEFAULT '1000' ,
  PRIMARY KEY (`id`),
  UNIQUE KEY `openid` (`openid`)
) ENGINE=MyISAM AUTO_INCREMENT=14044 DEFAULT CHARSET=utf8;

CREATE TABLE `jd_jianding` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `expert_id` int(11) DEFAULT NULL ,
  `gid` int(11) DEFAULT NULL ,
  `goods_value` varchar(50) DEFAULT NULL ,
  `result` varchar(500) DEFAULT NULL ,
  `jdtime` int(11) DEFAULT NULL ,
  `is_essence` tinyint(4) NOT NULL DEFAULT '0' ,
  `istrue` tinyint(4) DEFAULT '0' ,
  `wid` int(11) DEFAULT '0',
  `scan_num` int(11) DEFAULT '0' ,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_name` (`gid`),
  KEY `index_wid` (`wid`) USING BTREE
) ENGINE=MyISAM AUTO_INCREMENT=9142 DEFAULT CHARSET=utf8;

　　表wp_goods數據量10094，sys_users數據量14044， jd_jianding數據量9142。

　　執行sql：

SELECT 
  `g`.`id`,
  `g`.`title`,
  `g`.`upset_price`,
  `u`.`nickname`,
  `j`.`istrue` 
FROM
  `wp_goods` `g` 
  LEFT JOIN `sys_users` `u` 
    ON g.user_openid = u.openid 
  LEFT JOIN `jd_jianding` `j` 
    ON g.id = j.wid 
ORDER BY `g`.`id` DESC 
LIMIT 6 ;

　　耗時16秒，而本地數據庫執行耗時0.02毫秒。

　　原因分析：

　　1、explain/desc 發現left join索引不起作用。

explain SELECT 
  `g`.`id`,
  `g`.`title`,
  `g`.`upset_price`,
  `u`.`nickname`,
  `j`.`istrue` 
FROM
  `wp_goods` `g` 
  LEFT JOIN `sys_users` `u` 
    ON g.user_openid = u.openid 
  LEFT JOIN `jd_jianding` `j` 
    ON g.id = j.wid 
ORDER BY `g`.`id` DESC 
LIMIT 6 ;

　　分析結果：

id    select_type    table    partitions    type    possible_keys    key    key_len    ref    rows    filtered    Extra
1    SIMPLE    g    \N    ALL    \N    \N    \N    \N    10093    100.00    Using temporary; Using filesort
1    SIMPLE    u    \N    ref    openid    openid    153    mydb.g.user_openid    10    100.00    Using where
1    SIMPLE    j    \N    ALL    index_wid    \N    \N    \N    7975    100.00    Using where; Using join buffer (Block Nested Loop)

　　索引無效，Using join buffer (Block Nested Loop)相當於遍歷表查詢。

　　2、profile分析了下，發現幾乎所有耗時都在sending data且緩存sending cached result to clien沒開啟。

　　show variables like '%cache%';

　　query_cache_type為off，在配置文件/etc/my.cf中添加“query_cache_type = 1”配置項並重啟。

　　執行后耗時10s，如果將order by去掉后耗時3秒。即使是耗時3秒也是無法接受的。

　　通過profile分析下具體耗時

SHOW VARIABLES LIKE '%profil%'
SET profiling = 1;

SELECT 
  `g`.`id`,
  `g`.`title`,
  `g`.`upset_price`,
  `u`.`nickname`,
  `j`.`istrue` 
FROM
  `wp_goods` `g` 
  LEFT JOIN `sys_users` `u` 
    ON g.user_openid = u.openid 
  LEFT JOIN `jd_jianding` `j` 
    ON g.id = j.wid 
ORDER BY `g`.`id` DESC 
LIMIT 6 ;

show profile for query 1;

　　

　　發現幾乎所有耗時都在sending data部分。

　　3、查看jd_jianding表索引，show index from jd_jianding發現cardinality的值為1。

　　

Table    Non_unique    Key_name    Seq_in_index    Column_name    Collation    Cardinality    Sub_part    Packed    Null    Index_type    Comment    Index_comment
jd_jianding    0    PRIMARY    1    id    A    7975    \N    \N        BTREE        
jd_jianding    0    uk_name    1    gid    A    \N    \N    \N    YES    BTREE        
jd_jianding    1    index_wid    1    wid    A    1    \N    \N    YES    BTREE    

　　4、優化表jd_jianding，analyze table jd_jianding，再次執行仍然如此。

　　然而mysql的文檔時這么說的。The higher the cardinality, the greater the chance that MySQL uses the index when doing joins. 

　　An estimate of the number of unique values in the index. This is updated by running ANALYZE TABLE or myisamchk -a. Cardinality is counted based on statistics stored as integers, so the value is not necessarily exact even for small tables. The higher the cardinality, the greater the chance that MySQL uses the index when doing

　　大意如下：

   1)、它代表的是索引中唯一值的數目的估計值。如果是myisam引擎，這個值是一個准確的值。如果是innodb引擎，這個值是一個估算的值，每次執行show index 時，可能會不一樣
   2)、創建Index時(primary key除外)，MyISAM的表Cardinality的值為null，InnoDB的表Cardinality的值大概為行數；
   3)、值的大小會影響到索引的選擇
   4)、創建Index時，MyISAM的表Cardinality的值為null，InnoDB的表Cardinality的值大概為行數。
   5)、可以通過Analyze table來更新一張表或者mysqlcheck -Aa來進行更新整個數據庫
   6)、可以通過 show index 查看其值

　　5、查看表jd_jianding字段wid的值全為默認值0，於是將其中一條記錄的wid字段值update為非0；再次analyze table jd_jianding。

　　再次執行，效果杠杠的，耗時只有0.02毫秒。困擾兩天的問題終於得到了解決。

　　6、把步驟4修改的字段值還原回來。

 

　　后記，原因大致如下：

1、mysql沒有開啟查詢緩存。
2、新添加字段默認值都一樣，導致索引不可用。