有天发现一个带innerjoin的sql执行速度虽然不是很慢(0.1-0.2),但是没有达到理想速度。两个表关联，且关联的字段都是主键，查询的字段是唯一索引。
sql如下：
SELECT p_item_token.*, p_item.product_type FROM p_item_token INNERJOINp_itemONp_item.itemid=p_item_token.itemid WHERE p_item_token.token='db87a780427d4d02ba2bd49fac8xxx'; |
其中表p_item_token中itemid是主键，token是唯一索引。p_item中itemid是主键
按照理想速度，应该在0.03s左右正常。但实际为0.2左右，慢了不少。
直接EXPLAIN看计划
1EXPLAIN 2SELECT 3p_item_token.*, 4p_item.product_type 5FROM 6p_item_token 7INNERJOINp_itemONp_item.itemid=p_item_token.itemid 8WHERE 9p_item_token.token='db87a780427d4d02ba2bd49fac8xxx'; |
结果：
注意看上面大红框。p_item表中就是2w条数据，那这个就是全表扫描了。
不正常啊。
1EXPLAIN 2SELECT 3p_item_token.*, 4p_item.product_type 5FROM 6p_item_token 7INNERJOINp_itemONp_item.itemid=p_item_token.itemid 8WHERE 9p_item_token.token='db87a780427d4d02ba2bd49fac8xxx'; 10 11SHOWWARNINGS; |
结果2里面显示code=1003.后面有个sql语句。这个语句就是mysql把我们输入的sql语句，按照规则改写之后执行的最终语句。
1/*select#1*/ 2SELECT 3'0000eb612d78407a91a9b3854ffffffff'AS`itemid`,/*注:直接按主键把值查出来了*/ 4'db87a780427d4d02ba2bd49fac8cf98b'AS`token`, 5'2016-12-1610:46:53'AS`create_time`, 6''AS`ftoken`, 7`p_db`.`p_item`.`product_type`AS`product_type` 8FROM 9`p_db`.`p_item_token` 10JOIN`p_db`.`p_item` 11WHERE 12( 13( 14CONVERT( 15`p_db`.`p_item`.`itemid`USINGutf8mb4 16)='0000eb612d78407a91a9b3854fffffff' 17) 18) |
奇怪啊。Where中怎么有个CONVERT？我们知道，如果where条件中，等式的左边，也就是要查询的字段上有函数的话，就会导致慢。（我的理解：慢因为索引用不到了。索引的值是原始值，这个条件中用的却是处理后的值。）
注意看这函数，意思是把itemid这一列的编码转换成utf8mb4.
也就是说，这一列的编码不是utf8mb4!
也就是，两个连接表中，itemid的编码不同，一个是utf8,一个是utf8mb4！
打开表，把两个表中itemid这一列的编码都改成utf8。再次运行解释。
从解释结果来看已经没有问题了。
再看下结果2中的语句：
1/*select#1*/ 2SELECT 3'0000eb612d78407a91a9b3854fffffff'AS`itemid`, 4'db87a780427d4d02ba2bd49fac8cf98b'AS`token`, 5'2016-12-1610:46:53'AS`create_time`, 6''AS`ftoken`, 7'cxx'AS`product_type` 8FROM 9`toy_item_plat`.`p_item_token` 10JOIN`toy_item_plat`.`p_item` 11WHERE 121 |
这select中全是常量了。速度能不快吗？
执行结果0.036s。符合预期
经验总结:
explain可以查看执行计划是否符合预期，如果有出现rows较大的情况，则说明出现了全表扫描，将来会是性能瓶颈
showwarning的结果，则能看到优化器处理后的语句。如果与原始语句有出入，仔细对比研究能够发现实际问题。
