数据库——sql优化（百万数据优化方案）

一、sql数据库优化

1、索引

建立索引是数据库优化各种方案之中成本最低，见效最快的解决方案，一般来讲，数据库规模在几十万和几百万级别的时候见效最快，即便是有不太复杂的表关联，也能大幅度提高sql的运行效率。

 建立索引需要注意的地方

1、索引一般加在查询条件的关键字上，如果有多个查询条件关键字，还可以添加组合索引，写sql的时候需要注意，索引字段和sql字段需要保持一致，否则索引会无效。

2、建立索引的字段要区分度比较高，比如user表中有一个性别字段，性别字段无非男女两种值，区分度不好，建立索引效果不好，要选择区分度高的字段

3、建立组合索引，可以持续提升sql运行效率，但是也不要盲目，同样的要注意区分度，如果区分度不够高，就不要加了，多个字段，尽可能把区分度高的字段放在前面，另外，还要注意索引长度，这个索引要同时兼顾索引长度和区分度的平衡

4、索引会大幅提升查询效率，但是也会损耗查询后修改效率，要注意兼顾平衡，使用在一次插入，多次查询的表上效果最好，同时要注意的是，组合索引会不可避免的增加索引长度，会增加索引存储空间，注意索引长度和区分度平衡

5.并不是所有索引对查询都有效，SQL是根据表中数据来进行查询优化的，当索引列有大量数据重复时，SQL查询可能不会去利用索引
    
6.索引并不是越多越好，索引固然可以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率，因为 insert 或 update 时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有必要。  

7.在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。  

MySQL索引实现

MyISAM索引文件和数据文件是分离的，索引文件仅保存数据记录的地址。因此，MyISAM中索引检索的算法为首先按照B+Tree搜索算法搜索索引，如果指定的Key存在，则取出其data域的值，然后以data域的值为地址，读取相应数据记录。而在InnoDB中，表数据文件本身就是按B+Tree组织的一个索引结构，这棵树的叶结点data域保存了完整的数据记录。

MyISAM的索引方式也叫做“非聚集”的

 

2、分库分表分区

索引适合应对百万级别的数据量，千万级别数据量使用的好，勉强也能凑合，但如果是上亿级别的数据量，索引就无能为力了，因为单索引文件可能就已经上百兆或者更多了，那么，轮到的分表分区登场了

分库

可以按照业务分库，分流数据库并发压力，使数据库表更加有条理性。可以把查询库和系统库(增删改比较频繁的表)分开了，这样如果有大查询，不影响系统库

分表的方法

1、如果这个业务是有流程的，那么我们通常会设计一个历史表或者归档表，用来存放历史数据，这样能保证实时数据效率比较高

2、针对某一张大表，可以根据查询条件分成多张表，比如时间，我们可以将半个月或者10天的数据放到一张表里(看具体数据量，个人认为3000W是个上限，最好控制到百万级别)，每过10天，我们就自动创建一张数据库表，然后将数据插入，如此，按照时间查询，就要先定位去那种表中去取数，这样，效率能够得到大幅度提升.

当然，这么解决也有问题，比如跨表，需要union多张表，而且跨表没法支持索引

3、一般来讲，数据库中的大表毕竟只是一少部分，仅需要对这少部分大表进行分表就可以了，没必要小表也进行分表，增加维护开发难度

分区

分区的实现道理和分表一样，也是将相应规则的数据放在一起，唯一不同的是分区你只需要设定好分区规则，插入的数据会被自动插入到指定的区里。当然查询的时候也能很快查询到需要区，相当于是分表对外透明了，出现跨表数据库自动帮我们合并做了处理，使用起来比分表更加方便。

但是分区也有自己的问题，每一个数据库表的并发访问是有上限的，也就是说，分表能够抗高并发，而分区不能，如何选择，要考虑实际情况

 

3、数据库引擎

mysql比较常用的数据库引擎有两种，一种是innodb、一种是myisam

在一个千万级数据量复杂sql测试中，myisam的效率大概能够比innodb快1-2倍，虽然效率提升不是很明显，但是也有提升，后来查过一些资料，说之所以mysiam快，是因为他的数据存储结构、索引存储结构和innodb不一样的，mysiam的索引结构是在内存中存的

当然，mysiam也有弱点，那就是他是表级锁，而innodb是行级锁，所以，mysiam适用于一次插入，多次查询的表，或者是读写分离中的读库中的表，而对于修改插入删除操作比较频繁的表，就很不合适了

 

4、预处理

一般来说，实时数据(当天的数据)还是比较有限的，真正数据量比较大的是历史数据，基于大表历史数据的查询，如果再涉及一些大表关联，这种sql是非常难以优化的

实时数据(当天数据)

通过对对业务的抽象，可以放在缓存里面，提升系统运行效率

历史数据

大数据表历史数据且有表关联，通过常规sql难以优化，但是该数据通常有个共性，就是第二天去查询前一天的数据做分析报表，也就是说对时效性要求不高，这种情况的解决方案是预处理

处理：

将这些复杂表关联sql写成个定时任务在半夜执行，将执行的结果存入到一张结果表中，第二天直接查询结果表,如此，效率能得到十分明显提升

 

5、读写分离

在数据库并发大的情况下，最好的做法就是进行横向扩展，增加机器，以提升抗并发能力，而且还兼有数据备份功能

 

二、SQL语句具体操作 

1.对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。    
    
2.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：    
select id from t where num is null    
可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：    
select id from t where num=0    
    
3.应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。    
    
4.应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：    
select id from t where num=10 or num=20    
可以这样查询：    
select id from t where num=10    
union all    
select id from t where num=20    
    
5.in 和 not in 也要慎用，否则会导致全表扫描，如：    
select id from t where num in(1,2,3)    
对于连续的数值，能用 between 就不要用 in 了：    
select id from t where num between 1 and 3    
    
6.下面的查询也将导致全表扫描：    
select id from t where name like '%abc%'    
    
7.应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：    
select id from t where num/2=100    
应改为:    
select id from t where num=100*2    
    
8.应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：    
select id from t where substring(name,1,3)='abc'--name以abc开头的id    
应改为:    
select id from t where name like 'abc%'    
    
9.不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。    
    
10.不要写一些没有意义的查询，如需要生成一个空表结构：    
select col1,col2 into #t from t where 1=0    
这类代码不会返回任何结果集，但是会消耗系统资源的，应改成这样：    
create table #t(...)    
    
11.很多时候用 exists 代替 in 是一个好的选择：    
select num from a where num in(select num from b)    
用下面的语句替换：    
select num from a where exists(select 1 from b where num=a.num)    
    
12.尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。    
这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。    
    
13.尽可能的使用 varchar 代替 char ，因为首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些。    
    
14.任何地方都不要使用 select * from t ，用具体的字段列表代替“*”，不要返回用不到的任何字段。    
    
15.避免频繁创建和删除临时表，以减少系统表资源的消耗。

16.临时表并不是不可使用，适当地使用它们可以使某些例程更有效，例如，当需要重复引用大型表或常用表中的某个数据集时。但是，对于一次性事件，最好使用导出表。    
    
17.在新建临时表时，如果一次性插入数据量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果数据量不大，为了缓和系统表的资源，应先create table，然后insert。

18.如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先 truncate table ，然后 drop table ，这样可以避免系统表的较长时间锁定。    
    
19.尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该考虑改写。    
    
20.使用基于游标的方法或临时表方法之前，应先寻找基于集的解决方案来解决问题，基于集的方法通常更有效。

21.与临时表一样，游标并不是不可使用。对小型数据集使用 FAST_FORWARD 游标通常要优于其他逐行处理方法，尤其是在必须引用几个表才能获得所需的数据时。

22.在结果集中包括“合计”的例程通常要比使用游标执行的速度快。如果开发时间允许，基于游标的方法和基于集的方法都可以尝试一下，看哪一种方法的效果更好。

23.尽量避免大事务操作，提高系统并发能力。

24.尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。

25.不要在查询=前面使用函数，否则会导致索引不生效，举个栗子，where str=substring(“hello world”,6,8),这样是可以走索引的，但是 where substring(str,6,8)=“hello world” 是不会命中索引的

 

三、数据库访问性能优化

要正确的优化SQL，我们需要快速定位能性的瓶颈点，也就是说快速找到我们SQL主要的开销在哪里？

而大多数情况性能最慢的设备会是瓶颈点，如下载时网络速度可能会是瓶颈点，本地复制文件时硬盘可能会是瓶颈点，为什么这些一般的工作我们能快速确认瓶颈点呢，因为我们对这些慢速设备的性能数据有一些基本的认识，如网络带宽是2Mbps，硬盘是每分钟7200转等等。

计算机系统硬件性能从高到代依次为：

CPU——Cache(L1-L2-L3)——内存——SSD硬盘——网络——硬盘

 

根据数据库知识，我们可以列出每种硬件主要的工作内容：

CPU及内存：缓存数据访问、比较、排序、事务检测、SQL解析、函数或逻辑运算；

网络：结果数据传输、SQL请求、远程数据库访问（dblink）；

硬盘：数据访问、数据写入、日志记录、大数据量排序、大表连接。

 

根据当前计算机硬件的基本性能指标及其在数据库中主要操作内容，可以整理出如下图所示的性能基本优化法则：

这个优化法则归纳为5个层次：

1、  减少数据访问（减少磁盘访问）

2、  返回更少数据（减少网络传输或磁盘访问）

3、  减少交互次数（减少网络传输）

4、  减少服务器CPU开销（减少CPU及内存开销）

5、  利用更多资源（增加资源）

由于每一层优化法则都是解决其对应硬件的性能问题，所以带来的性能提升比例也不一样。传统数据库系统设计是也是尽可能对低速设备提供优化方法，因此针对低速设备问题的可优化手段也更多，优化成本也更低。我们任何一个SQL的性能优化都应该按这个规则由上到下来诊断问题并提出解决方案，而不应该首先想到的是增加资源解决问题。

以下是每个优化法则层级对应优化效果及成本经验参考：

 

四、为什么说B+tree比B 树更适合实际应用中操作系统的文件索引和数据库索引？

1）B+树的磁盘读写代价更低

B+树的内部结点并没有指向关键字具体信息的指针。因此其内部结点相对于B树更小。如果把所有同一内部结点的关键字存放在同一盘块中，那么盘块所能容纳的关键字数量也越多。一次性读入内存中的需要查找的关键字也就越多。相对来说IO读写次数也就降低了。

2) B+-tree的查询效率更加稳定

由于非终结点并不是最终指向文件内容的结点，而只是叶子结点中关键字的索引。所以任何关键字的查找必须走一条从根结点到叶子结点的路。所有关键字查询的路径长度相同，导致每一个数据的查询效率相当。

 

五、优化实例

（1）插入数据

1.导入大批量数据

     这个需要先关闭索引，插入数据后再打开索引。

1.1.针对MyISAM引擎可以通过以下方式提高导入数据效率，但是Innodb并不能提高这个效率。

    命令：alter table user disable keys; //关闭所有索引

               alter table user enable keys;  // 开启索引

1.2.对于Innodb类型的表，由于Innodb的表是根据主键的顺序保存的，所以将导入的数据按照主键的顺序，可以提高效率

      1. 2.1在导入数据前关闭唯一性校验也可以提高效率 set unique_checks=0

      1.2.2 关闭自动提交，set auto-commit=0 采用手动提交也可以提高效率

2.优化insert语句

    2.1如果同时插入多行，采用多个值表更好。

     inset into test values(1,2),(1,3),(2,3);

（2）排序 order by

目标：尽量减少额外的排序，通过索引直接返回有序数据。

排序情况有以下两种结果：

   1.通过有序索引顺序扫描直接返回有序数据。这里分析结果Extra：Using index ;例如：

         explain select customer_id from customer order by store_id;  //这里customer_id是主键，store_id是索引

   2. 通过返回数据进行排序，explain 返回的Extra结果是Using fileSort。这个是不好的。例如：

         explain select * from cutomer order by store_id;//store_id是一个索引

   方案：1>:where和order by使用相同的索引，并且order by 的顺序和索引顺序（如果复合索引）相同

              2>:order by 字段都是同为升序或者降序，否则索引不生效，使用了Using fileSort

              3>:当filesort索引无法避免情况下，想办法加快fileSort操作，设计到两次扫描算法和一次扫描算法，看情况使用某一种。

两次扫描算法：根据条件取出排序字段和行指针信息，之后再排序区排序，如果排序区不够在新建临时表。完成排序后在通过指针回表读取记录。

一次扫描算法：一次性取出满足条件的行的所有字段。然后再排序区完成排序后，直接输出数据，这个排序的时候内存消耗比较大，但是相比两次效率又高。

（3）分组group by 优化

默认情况下group by 对字段分组的时候，会排序。这和在查询order by 的情况类似。

1. 如果在在分组的时候不需要排序，最好关掉排序命令：order by null。

explain select name sum(money) from user group by name order by null;

（4）优化嵌套查询

1.某些子查询可以通过join来代替。

理由：join不需要在内存中创建一个临时表来存储数据。

explain select * from customer where customer_id not in (select customer_id from payment) ;

上面的语句用下面的语句代替

explain select * from customer a left join payment b on a.customer_id=b.customer where b.customer_id is null;

（5）优化or条件

1. 对于单独的两个索引

explain select  * from sales where id=2 or year =1998;    //id和year都是索引

这两个索引都是被使用到了的，但是这个查询时分别对两个条件进行查询，然后union两个结果的。

2. 如果对复合索引(id 和year是复合索引)，那么如果不能使用到索引，采用全文扫描。

 （6）优化分页查询

常见的分页查询，查询到“limit 2000,20”;时候就会出现先查询前面2200个，然后抛弃前面2000个，造成查询和排序代价非常大。优化方式如下：

1.在索引上完成排序分页的操作。根据主键关联回原表查询所需要的其他内容。

explain select a.last_name , a.first_name from user a inner join (select id from user order by id limit 2000,20) b on a.id=b.id;

2.把limit查询转换成某一个位置查询。可以通过把上一页的最后一条记录记下来。

select * from payment order by rental_id desc limit 2000,20;    //这样效率非常低下

如上面是通过 rental_id 降序来排列的 ，那么我们在查询 limit 1800,20时候，记录下2000位置的rental_id,加入这里的rental_id的值，假设这里的值是“5000” ，那么sql语句就可以转换成如下：

select * from payment where rental_id < 5000 order by rental_id desc limit 20;

注意事项： 这个只适合在排序字段不会出现重复值的特定环境，能够减轻分页翻页的压力，如果排序字段出现重复值，那么就会出现记录丢失。

 

（7）使用SQL提示

常见的SQL提示如下：

1. use index  这个表示希望sql去参考的索引，就可以让mysql不在考虑其他可用的索引了

explain select count(*) from user user index(idx_user_id);

2.ingore index 只是单纯的希望mysql忽略一个索引，或者多个。

explain select count(*) from rental ignore index(idx_rental_date)

3.force index 强制mysql使用一个索引

explain select * from user force index (idx_fk_inventory_id) where inventory_id >1;

默认inventory_Id都是大于1的，所以一般会全表扫描，如果强制使用这个所以，那么msyql还是会使用这个索引。