在40岁老架构师 尼恩的读者交流群(50+)中，尼恩一直在指导大家改造简历、指导面试。指导很多小伙伴拿到了一线互联网企业网易、美团、字节、如阿里、滴滴、极兔、有赞、希音、百度、美团的面试资格，拿到大厂offer。
其中，数据库的面试题，是核心和重点的题目，比如前段时间小伙伴面试美团，就遇到了下面这个 题：
索引的设计规范，你知道哪些？
小伙伴虽然用过索引，但是索引的设计规范忘记得一干二净，回答也是朦朦胧胧、支支吾吾， 当然，面试也就挂了。小伙伴赶紧来求助尼恩。
在这里，尼恩在这里给大家做一下系统化、体系化的梳理，按照下面的套路去回答，可以充分展示一下大家雄厚的 “技术肌肉”，让面试官爱到 “不能自已、口水直流”。
也一并把这个题目以及参考答案，收入咱们的 《尼恩Java面试宝典PDF》V154版本，供后面的小伙伴参考，提升大家的 3高 架构、设计、开发水平。
特别提示，尼恩的3高架构宇宙，尼恩Java面试宝典，都是持续升级。
《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF，请到文末公号【技术自由圈】取
索引是帮助MySQL高效获取数据的数据结构，注意，是帮助高性能的获取数据。
索引好比是一本书的目录，可以直接根据页码找到对应的内容，目的就是为了加快数据库的查询速度。
索引的存储原理大致可以概括为一句话：以空间换时间。
数据库在未添加索引, 进行查询的时候默认是进行全文搜索，也就是说有多少数据就进行多少次查询，然后找到相应的数据就把它们放到结果集中，直到全文扫描完毕。
数据库添加了索引之后，通过索引快速找到数据在磁盘上的位置，可以快速地读取数据，而不用从头开始全表扫描。
一般来说索引本身也很大，不可能全部存储在内存中，因此索引往往是存储在磁盘上的文件中的（可能存储在单独的索引文件中，也可能和数据一起存储在数据文件中）。
主键索引：primary key
唯一索引：
复合索引：
全文索引：
空间索引：
前缀索引：
优点：
缺点：
综合索引的优缺点：
数据库表中不是索引越多越好，而是仅为那些常用的搜索字段建立索引效果最佳!每个公司，都有自己的 设计规范，
尼恩这里的梳理的设计规范，可以作为大家参考。 当然，如果面试的时候能讲到这个水平，已经很牛掰了。
单值索引，建议以 idx_ 为开头，字母全部小写。
例如：alter table t1 add key idx_r1(r1)；
组合索引，建议以 dx_multi_ 开头，字母全部小写。
例如：alter table t1 add key idx_multi_1(r1,r2,r3) ;
唯一索引，建议以 udx_ 为开头，字母全部小写；如果是多值唯一索引，则命名方式类似 udx_multi_1 等。
例如：
alter table t1 add unique key udx_f1(r1)；
或者
alter table t1 add key udx_multi_1(r1,r2,r3);
全文索引，建议以 ft_ 开头，字母全部小写，并且建议默认用 ngram 插件。
例如：alter table t1 add fulltext ft_r1(r1) with parser ngram;
前缀索引，建议以 idx_ 开头，以 _prefix 结尾。
例如： alter table t1 add key idx_r1_prefix(r1(10));
函数索引，建议以 idx_func_ 开头，字母全部小写。
例如： alter table t1 add key idx_func_r1((mod(r1,4)));
索引本身有有序的，尽量选择整型列做索引，
所以，尽量不用uuid，而是使用雪花id，页段id，等整数id去建立索引 。
雪花id，页段id的源码和原理，请参见尼恩的《视频第32章：超高并发、超高可用1000W级 ID组件 架构与实操》
如果避免不了，只有字符串做索引，可以选择对字符类型做 HASH ，再基于 HASH 结果做索引；
主键列数据类型最好也是整型，
避免对不规则的字符串建立主键（由于 INNODB 表即索引，所以应该避免掉。不仅仅 UUID 非有序，而是因为单个 UUID 太大）
唯一性索引的值是唯一的，可以更快速的通过该索引来确定某条记录。
例如，学生表中学号是具有唯一性的字段。为该字段建立唯一性索引可以很快的确定某个学生的信息。
如果使用姓名的话，可能存在同名现象，从而降低查询速度。
经常需要ORDER BY、GROUP BY、DISTINCT和UNION等操作的字段，排序操作会浪费很多时间。
如果为其建立索引，可以有效地避免排序操作。
如果某个字段经常用来做查询条件，那么该字段的查询速度会影响整个表的查询速度。
因此，为这样的字段建立索引，可以提高整个表的查询速度。
索引的数目不是越多越好。
每个索引都需要占用磁盘空间，索引越多，需要的磁盘空间就越大。
修改表时，对索引的重构和更新很麻烦。
越多的索引，会使更新表变得很浪费时间。
如果索引的值很长，那么查询的速度会受到影响。
例如，对一个CHAR(100)类型的字段进行全文检索需要的时间肯定要比对CHAR(10)类型的字段需要的时间要多。
如果索引字段的值很长，最好使用值的前缀来索引。
例如，TEXT和BLOG类型的字段，进行全文检索会很浪费时间。
如果只检索字段的前面的若干个字符，这样可以提高检索速度。
表中的数据被大量更新，或者数据的使用方式被改变后，原有的一些索引可能不再需要。
数据库管理员应当定期找出这些索引，将它们删除，从而减少索引对更新操作的影响。
mysql会一直向右匹配直到遇到范围查询(>、<、between、like)就停止匹配，
比如a 1=”” and=”” b=”2” c=”“> 3 and d = 4 如果建立(a,b,c,d)顺序的索引，d是用不到索引的，如果建立(a,b,d,c)的索引则都可以用到，a,b,d的顺序可以任意调整。
注意：=和in可以乱序。
比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意顺序，
mysql的查询优化器会帮你优化成索引可以识别的形式
区分度的公式是count(distinct col)/count(*)，表示字段不重复的比例，比例越大我们扫描的记录数越少，
唯一键的区分度是1，而一些状态、性别字段可能在大数据面前区分度就 是0，
那可能有人会问，这个比例有什么经验值吗？
使用场景不同，这个值也很难确定，一般需要join的字段我们都要求是0.1以上，即平均1条扫描10条 记录
比如from_unixtime(create_time) = ’2014-05-29’就不能使用到索引，原因很简单，b+树中存的都是数据表中的字段值，但进行检索时，需要把所有元素都应用函数才能比较，显然成本 太大。
所以语句应该写成create_time = unix_timestamp(’2014-05-29’);
比如表中已经有a的索引，现在要加(a,b)的索引，那么只需要修改原来的索引即可
当单个索引字段查询数据很多，区分度都不是很大时，则需要考虑建立联合索引来提高查询效率
注意：选择索引的最终目的是为了使查询的速度变快。
https://www.cnblogs.com/chenhaoyu/p/8761305.html
https://zhuanlan.zhihu.com/p/391673897
mysql相关的面试题，是非常常见的面试题。
以上的内容，如果大家能对答如流，如数家珍，基本上 面试官会被你 震惊到、吸引到。
最终，让面试官爱到 “不能自已、口水直流”。offer， 也就来了。
在面试之前，建议大家系统化的刷一波 5000页 《尼恩Java面试宝典PDF》，里边有大量的大厂真题、面试难题、架构难题。很多小伙伴刷完后， 吊打面试官， 大厂横着走。
在刷题过程中，如果有啥问题，大家可以来 找 40岁老架构师尼恩交流。
另外，如果没有面试机会，可以找尼恩来改简历、做帮扶。
尼恩指导了大量的小伙伴上岸，前段时间，刚指导一个40岁+被裁小伙伴，拿到了一个年薪100W的offer。
……完整版尼恩技术圣经PDF集群，请找尼恩领取
《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》PDF，请到下面公号【技术自由圈】取↓↓↓