其实sql优化就是对索引的优化，不加索引的情况下，单表查询你怎么查时间复杂度都是O(n)，所以sql优化问题关键就在索引上。
mysql索引有两种类型，hash和tree，但是hash的局限性太多了，而且重复数据多时hash索引的效率下降的很快，所以就说一下我对最常用的btree索引的看法。
mysql的btree索引或者叫b＋tree索引就是一颗二叉搜索树，并且在二叉搜索树叶节点间加了指针以方便排序或查询某范围的数据等情况使用。
索引最大的问题就是在很多时候不能生效，网上跟索引有关的文章很多，基本上就是某某情况下索引不能生效，等等一大篇；
但是作为一个程序员如果死记硬背这些个那真没有用，找个文科生比咱们背的好。所以我总结了几点索引不能生效的原因，网上说的那些个都可以归到这几类里面。
1，sql写的不规范或者叫mysql查询引擎没有进行优化导致不能使索引生效。
举个例子，如果对某个varchar类型的字段建立了索引，而我在sql中条件写的是columnvlaue = 1(注意这是一个数字),这个时候字段类型和参数类型不匹配，因此在查询时索引不会生效。
其实查询引擎完全可以进行优化，或者编写sql的人完全可以将sql改的规范来避免这个问题。
2，mysql设计的btree不能支持如此查询。
举个例子，网上对于like查询有两种言论，一种是使用like查询索引不能生效，一种是使用like进行非最左前缀的查询索引不能生效；
当然，后者是正确的。mysql的btree索引只支持最左前缀匹配。但是你说它能设计为全部匹配么，当然可以，比如使用kmp算法进行子字符串匹配。
但是我估计mysql的设计人员实在不想再增加btree索引设计的复杂程度了，或者怕降低查询的效率（设子字符串长度为m，大字符串长度为n，匹配的时间复杂度会从O(M)变为O(n+m)）。
3，btree根本不支持此种查询。
比如，反向查询。你说我的条件是哪个字段不等于xx，你把这个条件放到二叉搜索树里面去搜索，它根本就不知道你想要查的数据在哪个子树上面。
因此就算使用索引，复杂度最坏的情况下也是O(n)，跟不使用根本没区别，所以这种情况也不会使用索引。
以上就是单表情况下索引不能生效的原因分析。
此外还有聚合索引以及多表联查时索引的使用。聚合索引mysql的处理很简单，
就是将几个字段拼到一起合为一个字段进行索引，因此索引中的第一个字段很重要，如果查询条件中没有第一个字段，
聚合索引是不能生效的。至于多表联查，其实最应该解决的是涉及到的数据数量，这个等我研究透彻了再说吧。