标签：为什么 varchar job2 job1 utf8 查询 索引 123 select

1、建表
CREATE TABLE `person` (
  `id` int NOT NULL AUTO_INCREMENT,
  `name` varchar(30) CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT NULL,
  `job1` varchar(50) CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT NULL,
  `job2` varchar(50) CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT NULL,
  `job3` varchar(50) CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `ind_123` (`job1`,`job2`,`job3`) USING BTREE
) ENGINE=InnoDB;

2、插入数据

可以从两方面来回答

1、索引树的问题，底层原理机制

1、如下表，建立了2个索引，那就就有两颗索引树，因为innodb是聚集索引，那么主键id就是聚集索引，ind_123就是二级索引

查询数据的时候，如果

Select * from person where job2="2",通过explain可以看到，并没有使用索引

但是如果使用

SELECT
	job1,
	job2，job3
FROM
	person
WHERE
	job2 = "2"
通过explain可以看到，使用了
ind_123索引，并且key_len长度为458，因为创建表的时候varchar字段都是用的utf-8，同时字段是允许为null的所以就是50*3+2+1=153  153*3=459   所以使用的是ind_123这个索引表的全表扫描

但是如果使用

EXPLAIN SELECT
	job1,
	job2,
	job3
FROM
	person
WHERE
	job1 = '1'
AND job2 = '2'
通过explain可以看到，使用了
ind_123索引，并且key_len长度为306，因为创建表的时候varchar字段都是用的utf-8，同时字段是允许为null的所以就是50*3+2+1=153  153*2=306 
所以使用的是ind_123这个索引表的索引扫描，并且索引类型用的是ref相比较index更快，原理就是指需要扫描出二级索引树中的部分数据，因为job1和job2的数据是确定了的！查询效率相比较之前的全表索引树扫描会更加快，避免了回表操作

所以，不能用*来笼统的作为查询条件，这里是有很大的优化空间的！

2、连接查询时，* 无法进入缓冲池

使用select * 放一些无用的列，只会白白的占用缓冲空间。浪费本可以提高性能的机会。

标签：为什么,varchar,job2,job1,utf8,查询,索引,123,select
来源： https://www.cnblogs.com/yslu/p/15906686.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。