Sql语句优化和索引
1.Innerjoin和左连接，右连接，子查询
A. inner join内连接也叫等值连接是，left/rightjoin是外连接。
SELECT A.id,A.name,B.id,B.name FROM A LEFT JOIN B ON A.id =B.id;
SELECT A.id,A.name,B.id,B.name FROM A RIGHT JOIN ON B A.id= B.id;
SELECT A.id,A.name,B.id,B.name FROM A INNER JOIN ON A.id =B.id;
经过来之多方面的证实inner join性能比较快，因为inner join是等值连接，或许返回的行数比较少。但是我们要记得有些语句隐形的用到了等值连接，如：
SELECT A.id,A.name,B.id,B.name FROM A,B WHERE A.id = B.id;
推荐：能用inner join连接尽量使用inner join连接
B．子查询的性能又比外连接性能慢，尽量用外连接来替换子查询。
Select* from A where exists (select * from B where id>=3000 and A.uuid=B.uuid);
A表的数据为十万级表，B表为百万级表，在本机执行差不多用2秒左右，我们可以通过explain可以查看到子查询是一个相关子查询(DEPENDENCE SUBQUERY);Mysql是先对外表A执行全表查询，然后根据uuid逐次执行子查询，如果外层表是一个很大的表，我们可以想象查询性能会表现比这个更加糟糕。
一种简单的优化就是用innerjoin的方法来代替子查询，查询语句改为：
Select* from A inner join B using(uuid) where b.uuid>=3000;
这个语句执行测试不到一秒；
C．在使用ON 和 WHERE 的时候，记得它们的顺序，如：
SELECT A.id,A.name,B.id,B.name FROM A LEFT JOIN B ON A.id =B.id WHERE B.NAME=’XXX’
执行过程会先执行ON 后面先过滤掉B表的一些行数。然而WHERE是后再过滤他们两个连接产生的记录。
不过在这里提醒一下大家：ON后面的条件只能过滤出B表的条数，但是连接返回的记录的行数还是A表的行数是一样。如：
SELECT A.id,A.name,B.id,B.name FROM A LEFT JOIN B ON A.id =B.id;
返回的记录数是A表的条数，ON后面的条件只起到过滤B表的记录数，而
SELECT A.id,A.name,B.id,B.name FROM A ,B WHERE A.id = B.id
返回的条数，是笛卡尔积后，符合A.id = B.id这个条件的记录
D．使用JOIN时候，应该用小的结果驱动打的结果（left join 左边表结果尽量小，如果有条件应该放到左边先处理，right join同理反向），同事尽量把牵涉到多表联合的查询拆分多个query(多个表查询效率低，容易锁表和阻塞)。如：
Select * from A left join B ona.id=B.ref_id where B.ref_id>10;
可以优化为：select * from (select * from A wehre id >10) T1 left join B onT1.id=B.ref_id;
2.建立索引,加快查询性能.
A．在建立复合索引的时候，在where条件中用到的字段在复合索引中，则最好把这个字段放在复合索引的最左端，这样才能使用索引，才能提高查询。
B．保证连接的索引是相同的类型，意思就是A表和B表相关联的字段，必须是同类型的。这些类型都建立了索引，这样才能两个表都能使用索引，如果类型不一样，至少有一个表使用不了索引。
C．索引，不仅仅是主键和唯一键，也可以是其他的任何列。在使用like其中一个有索引的字段列的时候。
如： select *from A name like ‘xxx%’;
这个sql会使用name的索引（前提name建立了索引）；而下面的语句就使用不了索引
Select * from A name like ‘%xxx’;
因为‘%’代表任何字符，%xxx不知道怎么去索引的，所以使用不了索引。
D.复合索引
比如有一条语句这样的：select* from users where area =’beijing’ and age=22;
如果我们是在area和age上分别创建索引的话，由于mysql查询每次只能使用一个索引，所以虽然这样已经相对不做索引时全表扫描提高了很多效率，但是如果area，age两列上创建复合索引的话将带来更高的效率。如果我们创建了（area,age,salary）的复合索引，那么其实相当于创建了（area,age,salary）,(area,age),(area)三个索引，这样称为最佳左前缀特性。因此我们在创建复合索引的应该将最常用作限制条件的列放在最左边，依次递减。
E.索引不会包含有NULL值的列
只要列中包含有NULL值都将不会被包含在索引中（除非是唯一值的域，可以存在一个NULL），复合索引中只要有一列含有NULL值，那么这一列对于此复合索引是无效的。所以我们在数据库设计时不要让字段的默认值为NULL.
F.使用短索引
对串列进行索引，如果可能应该指定一个前缀长度。例如，如果有一个CHAR(255)的列，如果在钱10个或者20字符内，多数值是唯一的，那么就不要对整个列进行索引。短索引不仅可以提高查询速度而且可以节省磁盘空间和I/O操作。
G．排序的索引问题
Mysql查询只是用一个索引，因此如果where子句中已经使用了索引的话，那么order by中的列是不会使用索引的。因此数据库默认排序可以符合要求情况下不要使用排序操作；尽量不要包含多个列的排序，如果需要最好给这些列创建复合索引。
3.limit千万级分页的时候优化。
A．在我们平时用limit,如：
Select * from A order by id limit 1,10;
这样在表数据很少的时候，看不出什么性能问题，倘若到达千万级，如：
Select * from A order by id limit10000000,10;
虽然都是只查询10记录，但是这个就性能就让人受不了了。所以为什么当表数据很大的时候，我们还继续用持久层框架如hibernate,ibatis就会有一些性能问题，除非持久层框架对这些大数据表做过优化。
B．在遇见上面的情况，我们可以用另外一种语句优化，如：
Select * from A where id>=(Select idfrom a limit 10000000,1) limit 10;
确实这样快了很多，不过前提是，id字段建立了索引。也许这个还不是最优的，其实还可以这样写：
Select * from A where id between 10000000and 10000010;
这样的效率更加高。
4.尽量避免Select * 命令
A.从表中读取越多的数据，查询会变得更慢。它会增加磁盘的操作时间，还是在数据库服务器与web服务器是独立分开的情况下，你将会经历非常漫长的网络延迟。仅仅是因为数据不必要的在服务器之间传输。
5.尽量不要使用BY RAND()命令
A．如果您真需要随机显示你的结果，有很多更好的途径实现。而这个函