作者爱谈话
忙忙碌碌的一周又过来了，这周最大的乐趣就是买了个小音箱，又能够上班的时候开始欢快的开始练琴了，程序员嘛，还是得造就点艺术细菌。哈哈
这周原本没想好写什么货色，刚好周五公司进行了外部技术分享，内容为《MySQL 索引解说 + 最佳实际》，摘出了几条重要，和较常见的和大家一起分享，当然还有很多没有波及到，对于索引的知识点，就不具体开展解说，原本想转载一篇文章与大家分享，然而低微的我还没加上原作者微信，有趣味的话能够公众号内回复“惟一索引和一般索引”。我将原文地址举荐给你。
当初你能够洗洗手，关上你的 Naviact 和王经理一起入手实际，常识排汇 + 100%
舒适提醒：文末附建表语句。
索引前戏
王经理 ????：天苍苍，野茫茫，索引 查问帮大忙。
小林小声 bb：经理如同个憨批。
王经理：林步动，你在说什么？
王经理的砖头
小林：没没没，我说经理，好才华！这个诗写的，啧啧啧，真是 ???? 牛掰 glass
王经理：算你小子，明天有眼力见。那我考考你，你能概括下索引的长处和毛病嘛？
小林：（淦，又考我）经理，《高性能 MySQL》一书中总结的 MySQL 的长处是
- 缩小查问须要扫描的数据量(放慢了查问速度)
- 缩小服务器的排序操作和创立长期表的操作(放慢了 groupby 和 orderby 等操作)
- 将服务器的随机 IO 变为程序 IO(放慢查问速度)
至于毛病嘛，就是 索引也是数据，须要存储，因而会带来额定的存储空间占用。其次，在插入，更新和删除操作的同时，须要保护索引，因而会带来额定的工夫开销
小美：步动，你明天好帅啊
小林：????????????????
王经理：明天，步动说的很对阿，我再来总结下索引的毛病
- 索引占用磁盘或者内存空间
- 减慢了插入更新操作的速度
然而实际上, 在肯定数据范畴内(索引没有超级多的状况下)，建设索引带来的开销是远远小于它带来的益处的，然而咱们依然要避免索引的滥用。
王经理：林步动，你自豪啥，快给我从桌子上下来！咱们明天的重点不在这里，重点是解说一下 MySQL 的索引具体在生产中的最佳实际办法。拿起小本本，关上 Naviact，动起来。
最佳实际
前置常识：EXPLAIN
1，最左前缀法令
EXPLAIN SELECT * FROM `employee_information` WHERE age = 23 AND position = "dev"
WHERE 条件列的，从索引的最左前列开始，且不跳过索引中的列，一旦未以最从左前列开始，索引就生效。意思就是 是兄弟，就来砍我啊，不对。应该是 带头大哥不能死，两头兄弟不能断
由最左前缀准则引申出的 索引冗余问题 ：依据最左索引准则，咱们不难得出，index(a,b) 相当于创立了二个索引 index(a)、index(a,b)。也能够类推，index(a,b,c)相当于创立了三个索引 index(a)、index(a,b)、index(a,b,c)。
那么，无妨多问本人一个为什么？???? 索引冗余会带来什么问题？一张表设置几个索引以内最佳？（能够参考阿里 Java 开发手册，或《高性能的 MySQL》一书）
2，不在索引列上做任何操作（计算、函数、（主动 or 手动）类型转换），会导致索引生效而转向全表扫描
`EXPLAIN SELECT * FROM employee_information` WHERE LEFT(name,3) = ‘bud’
“
拿该条 SQL 举例说明，我须要一条条取出 name，进行函数操作，而后逐条与限定的条件（bud）进行比拟，所以没方法用索引，只能进行全表扫描。
那么，会不会有这么一种状况。在你不经意的时候，MySQL 偷偷的在你的索引列上做了操作？导致咱们的索引生效了。
就比方，隐式转换？
3，存储引擎不能应用索引中范畴条件左边的列（若两头索引列用到了范畴（>、<、like 等），则前面的所以全生效。）
`EXPLAIN SELECT * FROM employee_information` WHERE name = ‘budongli’ AND age > 23 AND position = “dev”
“
能够看到 type = range，实际上 age 用到了索引（能够察看 key_len），只是说这个索引表白的是范畴，导致 position 用不上索引
4，尽量应用笼罩索引（只拜访索引的查问（索引列蕴含查问列）），缩小 SELECT * 语句
EXPLAIN SELECT name FROM `employee_information` WHERE name = 'budongli'
咱们在相应的 SELECT 操作中应用了笼罩索引，艰深一点讲就是 查问的列被索引笼罩，应用到笼罩索引查问速度会十分快，SQl 优化中现实的状态。
须要留神的是，当 Using where 和 Using index 同时呈现的时候，此时 Using where 只是用来从索引中查找数据，此数据如果不是用来过滤，那么就是用来读取，以防止回表读取数据行。
如果咱们只爱应用 SELECT *，那么完蛋。
Extra 会通知你，查问的列未被索引笼罩，进而通过 where 条件过滤获取所需数据，
5，MySQL 在应用不等于（！= 或者 <>）的时候无奈应用索引导致全表扫描，is null 或者 is null not 也不会走索引
EXPLAIN SELECT * FROM `employee_information` WHERE name != 'budongli'
这条和 Shit 一样的 SQL ????，在我是实习生的时候也写过。
尽可能把相似这种判断落在业务层，数据库很累，不给他加压力。爱护数据库，从你我做起。
6，like 以通配符结尾（‘$abc’）MySQL 索引生效会变成全表扫描操作
就像查字典一样，比方要查拼音首字母是 ch 的字，按程序翻完以 ch 结尾的页就能有后果，在这个 SQL 语句中咱们想去查 名字结尾是“budon”，利用索引程序查就 ok 了，很快就能查出来了。
EXPLAIN SELECT * FROM `employee_information` WHERE name like 'budon%'
但要是假如你想在字典里查拼音蕴含 an 的字，那就只能一页一页翻残缺个字典能力晓得哪些是须要的，此时就相当于无奈走索引，只能走全表扫描。
EXPLAIN SELECT * FROM `employee_information` WHERE name like '%budon%'
7，少用 or 或者 in
`EXPLAIN SELECT * FROM employee_information` WHERE name = “budongli” or name = “xiaomei”
“
MySQL 的查问优化器是一个非常复杂的部件，它应用了十分多的优化策略来生成一个最优的执行打算：在应用 or 或者 in 的时候，MySQL 不肯定会应用索引，MySQL 外部优化器会依据每张表或者索引的页面个数、索引的基数、索引和数据行的长度、索引的散布等七七八八，九九十十等多个因素去整体评估是否应用索引。有十分多的起因会导致 MySQL 抉择谬误的执行打算，比方统计信息不精确、不会思考不受其管制的操作老本（用户自定义函数、存储过程）。
归根结底，MySQL 认为的最优跟咱们想的不一样（咱们心愿执行工夫尽可能短，但 MySQL 值抉择它认为老本小的，但老本小并不意味着执行工夫短）等等。
所以说，MySQL 外部优化器有时候也是个笨蛋，很有可能选错。当然如果你感觉走一个固定的索引，这个 SQL 语句会快的飞起，请别客气应用 FORCE INDEX 与优化器进行 Battle
问题工夫到了
如果一张表的某个字段即能够建惟一索引，又能够建一般索引，假如你是公司的 DBA，从性能角度思考来讲，你会如何抉择？抉择的根据是什么？
（倡议小伙伴能够被动去思考思考，入手实际实际，当然公众号内也给你筹备了较为具体的分享，你能够在公众号内回复“惟一索引和一般索引”，我将与你分享）
建表语句
-- ----------------------------
-- Table structure for employee_information
-- ----------------------------
DROP TABLE IF EXISTS `employee_information`;
CREATE TABLE `employee_information` (`id` int(11) NOT NULL,
`name` varchar(24) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
`age` int(11) NOT NULL,
`position` varchar(20) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
`hire_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`) USING BTREE,
INDEX `hybrid_index`(`name`, `age`, `position`) USING BTREE,
INDEX `age`(`age`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;
-- ----------------------------
-- Records of employee_information
-- ----------------------------
INSERT INTO `employee_information` VALUES (1, 'budongli', 23, 'dev', '2020-06-12 22:21:24');
INSERT INTO `employee_information` VALUES (2, 'xiaomei', 22, 'dev', '2020-05-06 22:22:10');
INSERT INTO `employee_information` VALUES (3, 'jingliwang', 30, 'manager', '2018-06-01 22:22:37');
SET FOREIGN_KEY_CHECKS = 1;