记优化数据库的经历

一：针对where 条件 order by 字段 优化 （2014-10-22）

　　问题：只要加上order by 速度就很慢

　　介绍：

　　一个文章表，大小有1.6G，表结构是

　　id(主键递增)   nid(小说书id)  vid(小说章节id)  content(小说内容)  time(时间)

　　业务要求：搜索出每本小说的前12个最新章节

　　sql: 

　　 Select id,name,content From table where nid=1024 order by time desc limit 12

　　优化经历：

　　原本表中对nid这个字段加个索引，时间快了一点，但是只要使用order by就顿时慢了，所以就要想办法优化order by

　　对这块的优化，最好是使用联合索引，针对nid和time

　　ALTER TABLE table ADD INDEX nid_time_index(nid,time);

　　速度明显上升，问题解决

二：针对联合查询join order by  limit优化（2014-10-23）

     问题：表中400w+数据，left join联合查询，如果加上order by 后,速度慢很多

     原始sql：

          select * from t_people p left join t_team t on p.team_id=t.id order by p.pname limit 10;

     优化：

          先搜索再limit出最少的数据，10条数据，再去联合查询，还可以继续 在order by 的字段上添加索引并指定desc 或者 asc

           create  index  pnameindex  on  t_people (pname asc)

           select * from (select * from t_people p order by p.pname limit 10) p left join t_team t on p.team_id=t.id limit 10; 

     参考：http://blog.csdn.net/xiao__gui/article/details/8616224

总结：

    针对以上两个优化经历，可以得出结论是" mysql数据库是先搜索后排序 "，这样时间就消耗的多了，因此优化就是先筛选出需要的数据，再去排序

 

 三：

    1.谨慎使用TEXT/BLOB类型

      当列类型是TEXT或者BLOB时，我们应该特别注意，因为当选择的字段有 text/blob 类型的时候，无法创建内存表，只能创建硬盘临时表，而硬盘临时表的性能比内存表的性能差，所以如果非要使用TEXT/BLOB类型，应该单独建表，不要把TEXT/BLOB类型与核心属性混合在一张表中

   2.慎用子查询

      几乎所有子查询都可以改写为连接查询，有时候，连接查询的效率要比子查询高，所以把子查询改写成连接查询是一个不错的注意。如果一条使用子查询的select语句执行时间过长，那么就应该尝试把它改写为连接查询，看他是不是执行的更好。 

      select  * from  emp where  ename in  ( select ename from  ename);     

      select  emp.* from  emp inner  join  ename on  emp.ename=ename.ename;

   3.在DISTINCT列上增加索引

   4.在group by后面增加order by null

 　  在使用group by分组查询时，默认分组后，还会排序，可能会降低速度。如果不需要排序，那么可以在group by后面增加order by null，这样可以避免分组后排序

 

 

 

 

 

 

 

转载于:https://www.cnblogs.com/hanyouchun/p/4043707.html