首先，您可以根据业务需求构建表的结构，然后知道该表中包含哪些字段、每个字段是什么类型以及包含什么数据。
接下来设计表的结构后，接下来要做的就是设计表的索引。 设计这个索引时，首先要考虑的是将来对表进行查询时如何进行查询。
其实很多人可能会说，我刚设计了表格的结构，就知道将来怎么查询表格，我怎么知道呢？ 我真的想不到。
是的，没关系。 此时，在表结构设计完成后，不要加快索引设计。 因为此时不知道如何查询表。
之后，可以进入系统开发的一环。 也就是说，根据需求文档分阶段编写Java业务代码。 在编写代码的过程中，现在一般使用MyBatis作为数据持久层的框架。 一定会写很多MyBatis的DAO、Mapper和SQL吧。
那么，当系统开发差不多结束，功能全部就绪时，就可以考虑此时如何进行索引了。 因为系统中所有MyBatis的SQL语句都已经写入，所以您完全知道将为每个表启动什么查询语句。
此时，第一个索引设计原则到来，为SQL语句中的where条件、order by条件和group by条件设计索引。
也就是说，在where条件下，您要根据哪个字段过滤数据？ order by根据哪个字段排序？ group by根据哪个字段对聚合进行分组？
此时，可以设计一个或两三个联盟索引。 每个联合索引应尽可能包含后跟where、order by和group by的字段。 然后仔细检查每个SQL语句。 每个where、order by和group by之后的字段顺序是从联盟索引最左侧字段开始的部分吗？
例如，有一个名为index(a，b，c )的合并索引。 此时，一看有3个SQL，where a=？ and b=？ 如果您有以下部分：order by a、b和group by a，则where、order by和group by之后的所有字段都是从合并索引最左侧开始的部分字段，这样就可以了。 每个SQL语句都表示使用上索引。 所以在设计索引时，首先第一条是按照这个原则，确保每个SQL语句的where、order by和group by都可以使用索引。
设计索引时还必须考虑其他问题。 首先，一个是场基数问题。 举个例子，在10万行的数据中有10万个值的字段吧。 结果呢？ 这十万的值，不然就是0。 否则是1。 那么，其基数是2。 为什么？ 因为此字段的值是两个选择： 0和1。 在上述字段中创建索引比扫描整个表更好。 索引树只包含0和1两种值，快速二分查找也没有什么意义，因此在这些情况下，将基数较低的字段放入索引中的意义不大。
一般来说，编制索引并使用基数尽可能大的字段(即值多的字段)，可以发挥b树快速二分查找的好处。
然后，尽可能为那些字段类型较小的列设计索引。 例如，tinyint等。 该字段的类型很小，表示该字段本身的值占用了磁盘空间。 此时，检索时的性能也会稍好一些。
当然，这个字段类型的小列并不是绝对的。 在许多情况下，需要在类似varchar(255 )的字段中进行索引，并设计这样的索引，即使占用了大量的磁盘空间。 重要的是，不要在索引中包含基数过低的字段。 因为意义不太大。 当然，如果真的有这样的Varchar(255 )字段，你可能会觉得里面的值太大了，放在索引树中太多了，占用了磁盘空间。 那时，仔细想想，我们发现可以改变只在此Varchar )字段的前20个字符中创建索引的策略。 这意味着要为此字段中每个值的前20个字符创建索引
此时创建的索引实际上类似于keymy_index(name(20 )、age、course )。 在这种情况下，即使name是varchar )，索引树也只能为name的值提取前20个字符。
此时，在where条件下检索时，如果在name字段中进行检索，则首先在索引树中用name字段的前20个字符进行检索，然后查找前20个字符前缀一致的部分数据，然后返回集群索引，返回完整的name
但是，对于order by name，该排序不可用于索引，因为索引树中只包含前20个字符。 group by也一样。 我需要知道前缀索引。
设计了索引。 非常棒。 然后在SQL上这样写。 wherefunction(a )=xx，在索引的字段a中嵌入了函数。 你觉得索引也可以用吗？ 显然不行。 所以，不要让查询语句的字段生成任何函数或进行计算。
虽然我们已经介绍了设计索引时应注意的问题，但实际上我们可以设计好索引，使查询语句能够使用索引，注意字段基数、前缀索引和索引列集函数的问题，以便查询能够使用索引索引不会因为某些原因变得不可用。
其实查询基本上可以索引，但一般问题不是很大，只是插入起来有点讲究。 插入数据一定有主键吧。 如果有主键，就必须更新集群索引树。 插入数据时，它始终包含在索引中
各个字段的值吧，那联合索引的B+树是不是也要更新？对了，不停的增删改数据，就会不停的更新索引树。
所以因为插入的数据值可能根本不是按照顺序来的，很可能会导致索引树里的某个页就会自动分裂，这个页分裂的过程就很耗费时间，因此一般设计索引别太多，建议两三个联合索引就应该覆盖掉这个表的全部查询了。否则索引太多必然导致增删改数据的时候性能很差，因为要更新多个索引树。
另外很关键一点，建议主键一定是自增的，别用UUID之类的，因为主键自增，那么起码聚簇索引不会频繁的分裂，主键值都是有序的，就会自然的新增一个页而已，但是如果用的是UUID，那么也会导致聚簇索引频繁的页分裂。