首先sql优化，是一个比较大的话题，我不能说给某个表的某个字段加索引就可以了，就innodb存储引擎来说他采用是B+tree的方式
他的实现原理是二叉树如果这个字段重复数据过多哪二叉树就是以平行的方式展开加索引的意义不大
还浪费磁盘空间，我们呢要根基实际的业务情况来进行分析的，哪现在怎么说sql优化呢，我们说sql优化其实还是要了解mysql的
体系结构，是要知道一条SQL是怎么运行的我们才能更好的知道怎么去优化一条SQL！
当一条sql执行时首先调用
1:SQL接口：接受用户的SQL命令，并且返回用户需要查询的结果。
比如select from就是调用SQL Interface
2:是否开启查询缓存：如果mysql开启了查询缓存如果数据命中，MySQL会检索用户是否有权限，如果有mysql不会对sql进解析等操作
直接返回结果数据，否则进入下一阶段
优化点1：
MySQL将缓存存放在一个引用表，(这不是一个table，类似于HashMap的数据结构),通过一个哈希值索引，这个哈希值通过查询本身，
当前要查询的数据库,客户端协议版本号等一些可能影响结果的信息计算得来，所以2个查询在任何字符上的不同（空格，注释），都会
导致缓存不命中
如果查询中包含任何用户自定义函数、存储函数、用户变量、临时表、MySQL库中的系统表，其查询结果都不会被缓存 eg：NOW()
查询缓存写操作缺点：
MySQL查询缓存系统会跟踪SQL查询中涉及的每张表，当其中涉及查询的表发生结构和数据的变化，即和这张表相关的所有缓存数据
全部失效，也就是说在缓存中的表的认为写操作，MySQL都必须把对应的表设置为失效，如果查询缓存非常大或者碎片很多，这个操作就可能带来很大的系统消耗，
甚至导致系统僵死
查询缓存查询操作缺点：
A:任何的查询语句在开始之前都必须经过检查，即使这条 SQL语句 永远不会命中缓存
B:如果查询结果可以被缓存，那么执行完成后，会将结果存入缓存，也会带来额外的系统消耗
查询缓存都会提高系统性能，缓存和失效都会带来额外系统消耗，特别是写密集型应用（CPU占用高），只有当缓存带来的资源节约大于其本身消耗的资源时，
才会给系统带来性能提升, 可以尝试打开查询缓存，并在数据库设计上做一些优化
A: 用多个小表代替一个大表，注意不要过度设计
B: 批量插入代替循环单条插入
C: 合理控制缓存空间大小，一般来说其大小设置为几十兆比较合适
D: 可以通过 SQL_CACHE 和 SQL_NO_CACHE 来控制某个查询语句是否需要进行缓存
SQL_NO_CACHE 是禁止缓存查询结果，但并不意味着 cache 不作为结果返回给 query，之前的缓存结果之后也可以查询到
使用方式：
SELECT SQL_CACHE COUNT() FROM A;COUNT()就是看看有多少条。。
可以在 SELECT 语句中指定查询缓存的选项，对于那些肯定要实时的从表中获取数据的查询，或者对于那些一天只执行一次的查询，
都可以指定不进行查询缓存，使用 SQL_NO_CACHE 选项。对于那些变化不频繁的表，查询操作很固定，可以将该查询操作缓存起来
，这样每次执行的时候不实际访问表和执行查询，只是从缓存获得结果，可以有效地改善查询的性能，使用 SQL_CACHE 选项
对于查询缓存的一些操作
FLUSH QUERY CACHE : 清理查询缓存内存碎片
RESET QUERY CACHE : 从查询缓存中移出所有查询
FLUSH TABLES : 关闭所有打开的表，同时该操作将会清空查询缓存中的内容
3：解析器：sql传递到解析器的时候会被解析器验证和解析（解析器是由Lex和YACC实现的，是一个很长的脚本）
主要功能:1>将SQL语句分解成数据结构，并将这个结构传到后续步骤，以后的sql语句的传递和处理就是基于这个结构
:2>如果SQL语句在分解成数据结构中遇到错误，哪就说明这个sql是不合理的
4：查询优化器：SQL语句会使用查询优化器对查询进行优化。他使用的是“选取-投影-联接”策略进行查询。
用一个例子就可以理解： select id,name from user where name= Tom;
这个select 查询先根据where 语句进行选取，而不是先将表全部查询出来以后再进行name过滤
这个select查询先根据uid和name进行 属性投影，而不是将属性全部取出以后再进行过滤
将这两个查询条件联接起来生成最终查询结果
5：执行计划 - 查询执行引擎 - 调用API接口查询 -（ InnoDB,DBD…） - 数据库