mysql 优化【1】

标签：isp   数据量   千万   let   完全   aci   排序   索引   ica   

报表需求1：从六千多万条数据中找需要的top100

方法：1.mysql explain 2.索引

由于数据量大，因此我们需要通过索引的方式降低搜索时间，不加索引FineReport直接报了sql时间过长的错误。

因此在对应的月份、用户等字段加了联合索引（保证这些选取的字段不为空，联合索引有最左匹配的说法，空了就全表搜了）

加完索引时间从没法搜降到了五秒左右。

报表需求2：从六千多万条数据*n月中找sum、avg等最大的top100

 sum、avg通过索引也可以降低执行时间。个人想法是通过地区表通过exist的方式计算哪些可选项，但是。。。可能还是比较麻烦，那就算了

同事：六千万条，从sql入手还是太慢了，想别的办法

待续。。。

mysql explain

 https://www.cnblogs.com/tufujie/p/9413852.html

explain出来的信息有10列，分别是id、select_type、table、type(对表访问类型)、possible_keys(可能使用的索引)、key(实际索引)、key_len、ref、rows(扫描出的行数，估算的行数)、Extra

mysql 联合索引

多个字段同时建立的索引(有顺序，ABC，ACB是完全不同的两种联合索引)（abc就是建a/ab/abc三个索引）

1.最左匹配

　　如abc，先匹配a，再bc，如果直接bc会不使用索引

2.最常用、筛选数据最多的字段放前边

mysql 索引btree hash

 hash索引一次就能定位，btree需要从根节点到叶子节点，最后才到具体页

所以hash快，但是其缺点是：1.不支持范围查询(between)，只支持（=、in、<=>）

　　2.btree可排序，hash不可以

　　3.hash组合索引，通过所有的加一块，才算hash，所以只拿前几个进行搜索，不走索引

　　4.当遇见大量Hash值相等的情况，hash不一定比btree快

mysql 索引 <=>、in、not in

 小数据量不走索引，大的走，所以还是通过explain看比较好

mysql 优化【1】

标签：isp   数据量   千万   let   完全   aci   排序   索引   ica   

原文地址：https://www.cnblogs.com/tillnight1996/p/12787877.html