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

　　表結構及現(xiàn)象描述：

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數(shù)據(jù)量10094，sys_users數(shù)據(jù)量14044， jd_jianding數(shù)據(jù)量9142。

　　執(zhí)行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秒，而本地數(shù)據(jù)庫執(zhí)行耗時0.02毫秒。

　　原因分析：

　　1、explain/desc 發(fā)現(xiàn)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分析了下，發(fā)現(xiàn)幾乎所有耗時都在sending data且緩存sending cached result to clien沒開啟。

　　show variables like '%cache%';

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

　　執(zhí)行后耗時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;

　　

　　發(fā)現(xiàn)幾乎所有耗時都在sending data部分。

　　3、查看jd_jianding表索引，show index from jd_jianding發(fā)現(xiàn)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、優(yōu)化表jd_jianding，analyze table jd_jianding，再次執(zhí)行仍然如此。

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

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

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

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

?

　　后記，原因大致如下：

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

http://www.cnblogs.com/rwxwsblog/p/5684213.html

轉載于:https://www.cnblogs.com/duanxz/archive/2013/06/14/3135450.html

總結

以上是生活随笔為你收集整理的mysql索引无效且sending data耗时巨大原因分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。