Mysql中where条件一个单引号引发的性能损耗

Posted 2020-10-18 似水流年g

日常写SQL中可能会有一些小细节忽略了导致整个sql的性能下降了好几倍甚至几十倍,几百倍。以下这个示例就是mysql语句中的一个单引号(\'\')引发的性能耗损，我相信很多朋友都遇到过，甚至还在这样写。

先看下我的表结构:

CREATE TABLE `d_sku` (
  `id` varchar(36) NOT NULL,
  `commodity_id` varchar(36) DEFAULT NULL,
  `counts` int(11) DEFAULT NULL,
  `price` double(15,2) DEFAULT NULL,
  `status` int(11) DEFAULT NULL,
  `location` varchar(100) DEFAULT NULL,
  `create_time` datetime DEFAULT NULL,
  `create_id` varchar(36) DEFAULT NULL,
  `modify_time` datetime DEFAULT NULL,
  `provalue_str` varchar(500) DEFAULT NULL,
  `category_id` varchar(36) DEFAULT NULL,
  `customer_id` varchar(36) DEFAULT NULL,
  `cert_no` varchar(100) DEFAULT NULL,
  `profit` double DEFAULT NULL,
  `check_cargo` int(11) DEFAULT \'0\',
  `check_time` datetime DEFAULT NULL,
  `keep_last_checked` int(11) DEFAULT NULL,
  `approval_status` int(11) DEFAULT \'0\',
  `code` varchar(30) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `index_price` (`price`) USING BTREE,
  KEY `index_category_status` (`category_id`,`status`) USING BTREE,
  KEY `index_modifytime` (`modify_time`) USING BTREE,
  KEY `index_customerId_categoryId` (`customer_id`,`category_id`) USING BTREE,
  KEY `index_certNo_customerId` (`cert_no`,`customer_id`) USING BTREE,
  KEY `index_provaluestr` (`provalue_str`(320)) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC

一个电商平台的SKU数据库表结构模式，该表中数据条数376138。以此下两种查询方式看下执行效率。查询语句都是从该表中查询一条数据分类为d2a17030-149d-11e5-a9de-000c29d7a3a0并且编号为5186354366的数据。

1.实例测试

1.对查询内容添加单引号

SELECT * FROM d_sku d where category_id=\'d2a17030-149d-11e5-a9de-000c29d7a3a0\' and  d.cert_no=\'5186354366\';

【消息】：执行成功，当前返回：[1]行，耗时：[1ms.]。查询速度非常快。

2.对查询内容不添加单引号

SELECT * FROM d_sku d where category_id=\'d2a17030-149d-11e5-a9de-000c29d7a3a0\' and  d.cert_no=5186354366;

【消息】：执行成功，当前返回：[1]行，耗时：[1210ms.]发现两者之间的执行效率显而易见啊。

 2.两者区别分析

这样一查询效果真的是显而易见，添加单引号查询才1ms，不添加单引号查询的耗时是1210ms.一条数据就这么明显了。可想而知这种性能损失有多大。但是为什么会这样呢？先从分析索引看起。使用关键词 “explain” 查看sql执行效率详细（关键词使用介绍点传送门）。

explain  SELECT * FROM d_sku d where category_id=\'d2a17030-149d-11e5-a9de-000c29d7a3a0\' and  d.cert_no=\'5186354366\';

explain  SELECT * FROM d_sku d where category_id=\'d2a17030-149d-11e5-a9de-000c29d7a3a0\' and  d.cert_no=5186354366;

 

图一:添加单引号

图二:未添加单引号

两条数据对比分析:

图一:

添加单引号后的性能详情,其中表头key这里显示出来真正使用了组合索引“index_certNo_customerId” ，其中这两个索引对应的列正好是“category_id”和“cert_no”。再看rows这，表示查询这条数据只检索了一条数据，因为是这里索引生效了，所以通过“cert_no”编号直接查询到了数据。

图二:

未添加单引号后的性能详情，发现真正使用的索引只有“index_category_status”,回到创建表结构的时候可以发现这条索引信息是添加`category_id`,`status`这两个列的，表示只用到了category_id,而第二个条件的cert_no列并没有用到索引，所以性能的损耗就在这里发生了。

总结:

原因就是因为我们创建表结构的时候cert_no字段是varchar类型的,而where时未添加单引号的时候参数是被做为数字类型来使用的，那不同的类型做查询的时候肯定是要转型的，数据类型转换的话就无法正常使用索引了。所以可以得到一个结论就是Int类型的数据在转换varchar再使用是不会使用索引的。我们可以修改表结构将cert_no改为int类型后在使用不添加单引号的参数查询时性能也就是正常的了。同样也是可以通过添加单引号来实现。