MySQL数据库在使用时的注意事项

1.什么情况下应该使用组合索引而非单独索引呢？

假设有条件语句a=a and b=b，如果a和b是两个单独的索引，在and条件下只有一个索引起作用，对于b则要逐个判断，而如果使用组合索引(a, b)，只要遍历一棵树就可以了，大大增加了效率。

但是对于a=a or b=b，由于是或的关系，因而组合索引是不起作用的，因而可以使用单独索引，这个时候，两个索引可以同时起作用。

2.如果有组合索引，还需要单列索引吗？

如果组合索引是(a, b)，则对于条件a=a，是可以用上这个组合索引的，因为组合索引是先按照第一列进行排序的，所以没必要对于a单独建立一个索引，但是对于b=b就用不上了，因为只有在第一列相同的情况下，才比较第二列，因而第二列相同的，可以分布在不同的节点上，没办法快速定位。

3.为什么索引要有区分度，组合索引中应该讲有区分度的放在前面？

如果没有区分度，例如用性别，相当于把整个大表分成两部分，查找数据还是需要遍历半个表才能找到，使得索引失去了意义。?

4.索引是越多越好吗？

当然不是，只有在必要的地方添加索引，索引不但会使得插入和修改的效率降低，而且在查询的时候，有一个查询优化器，太多的索引会让优化器困惑，可能没有办法找到正确的查询路径，从而选择了慢的索引。

5.为什么不要在更新频繁的字段上建立索引

更新一个字段意味着相应的索引也要更新，更新往往意味着删除然后再插入，索引本来是一种事先在写的阶段形成一定的数据结构，从而使得在读的阶段效率较高的方式，但是如果一个字段是写多读少，则不建议使用索引。

6.为什么不要使用not等负向查询条件

你可以想象一下，对于一棵b+树，跟节点是40，如果你的条件是等于20，就去左面查，你的条件等于50，就去右面查，但是你的条件是不等于66，索引应该咋办？还不是遍历一遍才知道。

7.为什么模糊查询不要以通配符开头

对于一棵b+树来讲，如果根是字符def，如果通配符在后面，例如abc%，则应该搜索左面，例如efg%，则应该搜索右面，如果通配符在前面%abc，则不知道应该走哪一面，还是都扫描一遍吧。

8.为什么or要改成in，或者使用union

or查询条件的优化往往比较难找到最佳的路径，尤其是or的条件比较多的时候，尤其如此，对于同一个字段，使用in就好一些，会对in里面的条件进行排序，并统一通过二分搜索的方法处理。对于不同的字段，使用union，则可以让每一个子查询都使用索引。

9.为什么数据类型应该尽量小，常用整型来代替字符型，长字符类型可以考虑使用前缀索引？

因为数据库是按照页存放的，每一页的大小是一样的，如果数据类型比较大，则页数会比较多，每一页放的数据会比较少，树的高度会比较高，因而搜索数据要读取的i/o数目会比较多，插入的时候节点也容易分裂，效率会降低。使用整型来代替字符型多是这个考虑，整型对于索引有更高的效率，例如ip地址等。如果有长字符类型需要使用索引进行查询，为了不要使得索引太大，可以考虑将字段的前缀进行索引，而非整个字段。

10.sql优化思路

一、如何收集有问题的sql语句

1）mysql 数据库提供了慢sql日志功能，通过参数slow_query_log，获取执行时间超过一定阈值的sql语录列表。

2）没有使用索引的sql语句，可以通过long_queries_not_using_indexes参数开启。

3）参数min_examined_row_limit，扫描记录数大于该值的sql语句才会被记入慢sql日志。

二、找到有问题的语句，接下来就是通过explainsql，获取sql的执行计划，是否通过索引扫描记录，可以通过创建索引来优化执行效率。是否扫描记录数过多。是否持锁时间过长，是否存在锁冲突。返回的记录数是否较多。

三、定制化的优化。

1）没有被索引覆盖的过滤条件涉及的字段，在区分度较大的字段上创建索引，如果涉及多个字段，尽量创建联合索引。

2）扫描记录数非常多，返回记录数不多，区分度较差，重新评估sql语句涉及的字段，选择区分度高的多个字段创建索引

3）扫描记录数非常多，返回记录数也非常多，过滤条件不强，增加sql过滤条件

4）schema_redundant_indexes查看有哪些冗余索引。?

如果多个索引涉及字段顺序一致，则可以组成一个联合索引

5）schema_unused_indexes查看哪些索引从没有被使用。