关于做服饰网站的首页,国有企业网站建设,网站建设怎么谈,优化营商环境条例概述最近做查询#xff0c;统计和汇总。由于数据量比较庞大#xff0c;大部分表数据上百万#xff0c;甚至有的表数据上千万。所以在系统中做sql优化比较多#xff0c;特此写一篇文章总结一下关于sql优化方面的经验。导致查询缓慢的原因1、数据量过大2、表设计不合理3、sql…概述最近做查询统计和汇总。由于数据量比较庞大大部分表数据上百万甚至有的表数据上千万。所以在系统中做sql优化比较多特此写一篇文章总结一下关于sql优化方面的经验。导致查询缓慢的原因1、数据量过大2、表设计不合理3、sql语句写得不好4、没有合理使用索引下面主要针对sql语句的优化和索引优化做个总结。针对SQL语句的优化1、查询语句中不要使用 *2、尽量减少子查询使用关联查询(left join,right join,inner join)替代3、减少使用IN或者NOT IN ,使用existsnot exists或者关联查询语句替代4、or 的查询尽量用 union或者union all 代替(在确认没有重复数据或者不用剔除重复数据时union all会更好)5、合理的增加冗余的字段(减少表的联接查询)6、增加中间表进行优化(这个主要是在统计报表的场景后台开定时任务将数据先统计好尽量不要在查询的时候去统计)7、建表的时候能使用数字类型的字段就使用数字类型(type,status...)数字类型的字段作为条件查询比字符串的快8、那些可以过滤掉最大数量记录的条件必须写在WHERE子句的最末尾索引优化如果针对sql语句已经没啥可以优化的那我们就要考虑加索引了。--说索引前需要explain查看sql的执行计划1 id SELECT识别符。这是select查询序列号。这个不重要2 select_type 表示查询中每个select子句的类型(简单OR复杂)有以下几种值 1 simple 查询中不包含查询或者UNION(联合查询) 2 PRIMARY 查询中若包含任何复杂的子部分最外层查询则被标记为PRIMARY 3 UNION 表示连接查询的第2个或后面的查询语句。 4 DEPENDENT UNION UNION 中的第二个或者后面的select语句取决于外面的查询 5 UNION RESULT 连接查询的结果 6 SUBQUERY 子查询中的第一个select语句 7 DEPENDENT SUBQUERY 子查询中的第一个select语句取决于外面的查询 8 DERIVED select(from子句的子查询)3 table 表示查询的表4 type 表示表的连接类型以下的连接类型的顺序是从最佳类型到最差类型 1 syste 表仅有一行这是const类型的特例平时不会出现 2 const 数据表最多只有一个匹配行因为只匹配一行数据所以很快常用于PRIMARY KEY 或者UNIQUE查询可理解为是最优化的。 3 eq_ref mysql手册是这样说的 对于每个来自前面的表的行组合从该表中读取一行。 这可能是最好的联接类型除了const类型。他用在一个索引的所有部分被联接使用并且并且索引是UNIQUE或PRIMARY KEY eq_ref可以用于使用比较带索引的列。 4 ref 查询条件索引既不是UNIQUE 也不是PRIMARY KEY 的情况ref可用于或操作符的带索引的列。 5 ref_or_null 该联接类型如同ref但是添加了Mysql可以专门搜索包含null值的行在解决子查询中经常使用该联接类型的优化。 以上这五种情况都是很理想的索引使用情况。 6 index 该连接类型与ALL相同除了只有索引树被扫描。这通常比ALL快因为索引文件通常比数据文件小。 7 ALL 对于每个来自先前的表的行组合进行完整的表扫描。5 possible_key 指出Mysql能使用哪个索引在该表中找到行。 如果该列为NULL 说明没有使用索引可以对该列创建索引来提高性能6 Key 显示mysql实际决定使用的索引如果没有选择索引键是null 可以强制使用索引或者忽略索引 强制使用索引USE index(列名) 忽略使用索引IGNORE INDEX(列名)7 key_len 显示mysql决定使用的键长度。如果键是NULL则长度为NULL。 注意key_len 是确定了mysql将实际使用的索引长度8 ref 显示使用哪个列或常数与key一起从表中选择行9 rows 显示mysql认为它执行查询时必须检查的行数10 extra 关于MYSQL如何解析查询的额外信息。Using temporary和Using filesort意思MYSQL根本不能使用索引结果是检索会很慢 说明extra列返回的描述的意义 Distinct 一旦mysql找到了与行相联合匹配的行就不再搜索了。 Not exists mysql优化了LEFT JOIN一旦它找到了匹配LEFT JOIN标准的行就不再搜索了。 Range checked for each Record(index map:#) 没有找到理想的索引因此对从前面表中来的每一个行组合mysql检查使用哪个索引并用它来从表中返回行。这是使用索引的最慢的连接之一。 Using filesort 看到这个的时候查询就需要优化了。mysql需要进行额外的步骤来发现如何对返回的行排序。它根据连接类型以及存储排序键值和匹配条件的全部行的行指针来排序全部行。 Using index 列数据是从仅仅使用了索引中的信息而没有读取实际的行动的表返回的这发生在对表的全部的请求列都是同一个索引的部分的时候。 Using temporary 看到这个的时候查询需要优化了。这里mysql需要创建一个临时表来存储结果这通常发生在对不同的列集进行ORDER BY上而不是GROUP BY上。 Where used 使用了WHERE从句来限制哪些行将与下一张表匹配或者是返回给用户。如果不想返回表中的全部行并且连接类型ALL或index这就会发生或者是查询有问题。使用explain查看sql执行计划后我们主要先看下type属性表示连接的类型如果是ALL这种那就需要优化了再看下possible_key属性表示可以使用的索引如果没有则为nullkey属性表示mysql实际决定使用的索引如果没有选择索引键是nullrows 表示mysql认为它执行查询时必须检查的行数行数越多效率越低。篇幅有限关于sql方面的优化就介绍到这了后面会分享更多关于优化方面的内容感兴趣的朋友可以关注下
