sql优化原则
尽量使用性能高的比如left join等，尽量减少数据查询的column，尽量不要查询冗余数据，like的话“%%”是没有 办法使用索引的，但是“%”是可以使用索引的
having以前一直不知道到底真正的用途是什么，觉得跟where这不是一样的吗，现在区分开来了
因为where是对结果集的筛选，若分组之后就没法使用where了，
所以having应运而生，having就是对分组后的数据进行筛选的，搭配group by 放在其之后，如果有order by 则也放在order by之后
mysql数据库的引擎有8种，
一般常用的有3中，innodb，这种是事务性的，所以一些安全性的sql，使用它，这样可保证数据的一致性
myiasm，这种是可以建立全文索引的，所以如果要对全文进行全文索引查询，那么可以在简历数据库的时候使用这个，但是虽然是索引，但是要注意，字符越少，它的索引越有可能无法创建，必须是有连接性，有规律的，这样索引的命中率才大
memory，这种索引就类似于memcache这种了，就是一个缓存，很快，但是一旦挂掉，那么数据库就丢失了。
索引的建立是要消耗空间的，在mysql中如果对一个键建立索引，那么会产生myf还是什么文件的了，挺大的
暂时就记得这么多了，还有好几个知识点不太记得了，记起来再写
二、mysql的视图并不是临时表，而是真正的数据，对视图中的数据进行操作，数据表中的数据也会改变，可定义为是否可更新
视图有很多优点，主要表现在：
•视点集中
•简化操作
•定制数据
•合并分割数据
•安全性
视图也存在一些缺点：
最大的缺点就是视图带来的更新负担，比如源数据改了，那么视图中要做相应更新，视图中数据改了源数据也要做同步
三、自定义函数的使用
由于sql分组有问题，
导致查询出来的虽然数据没有问题，但是牵扯到游标，所以count计算的数量是它实际数据条数的倍数，
所以跟之前修改之后修改写的关于分组表的sql在性能分析上可能之前的sql占优，但是
由于分组的问题，导致游标下移查询倍数，虽然是temp的但是游标还是要走的，游标也是为什么查询速率快的原因
PS：这里要十分注意，有可能的是，直接使用mysql是没有问题的，但是有可能使用工具，比如说mysql的图形化工具跟
jdbc或者是是别的orm框架什么的可能就会有这样的问题，游标的问题
摘录：
本文从游标的基本概念，到生命周期来谈游标。游标是非常邪恶的一种存在，使用游标经常会比使用面向集合的方法慢2-3倍，当游标定义在大数据量时，这个比例还会增加。如果可能，尽量使用while,子查询，临时表，函数，表变量等来替代游标，记住，游标永远只是你最后无奈之下的选择，而不是首选。
游标是邪恶的！
