sql优化

sql优化

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
-- sql优化遵守原则
-- 1.减少数据访问： 设置合理的字段类型，启用压缩，通过索引访问等减少磁盘IO
-- 2.返回更少的数据： 只返回需要的字段和数据分页处理 减少磁盘io及网络io
-- 3.减少交互次数： 批量DML操作，函数存储等减少数据连接次数
-- 4.减少服务器CPU开销： 尽量减少数据库排序操作以及全表查询，减少cpu 内存占用
-- 5.利用更多资源： 使用表分区，可以增加并行操作，更大限度利用cpu资源

-- 总结到SQL优化中，就三点:
-- 最大化利用索引；
-- 尽可能避免全表扫描；
-- 减少无效数据的查询；

-- sql语句执行顺序
1. select
2. distinct <select_list>
3. from <left_table>
4. <join_type> join <right_table>
5. on <join_condition>
6. where <where_condition>
7. group by <group_by_list>
8. having <having_condition>
9. order by <order_by_condition>
10.limit <limit_number>  


-- sql优化
一、避免不走索引的场景
1.见博客'索引'索引失效情况（以下为补充）
2.like--被代替->instr
3.尽量避免使用 or，会导致数据库引擎放弃索引进行全表扫描
二、SELECT语句其他优化
1. 避免出现select *
首先，select * 操作在任何类型数据库中都不是一个好的SQL编写习惯。
使用select * 取出全部列，会让优化器无法完成索引覆盖扫描这类优化，会影响优化器对执行计划的选择，也会增加网络带宽消耗，更会带来额外的I/O,内存和CPU消耗。
建议提出业务实际需要的列数，将指定列名以取代select *。

2. 避免出现不确定结果的函数
特定针对主从复制这类业务场景。由于原理上从库复制的是主库执行的语句，使用如now()、rand()、sysdate()、current_user()等不确定结果的函数很容易导致主库与从库相应的数据不一致。另外不确定值的函数,产生的SQL语句无法利用query cache。

3.多表关联查询时，小表在前，大表在后。
在MySQL中，执行 from 后的表关联查询是从左往右执行的（Oracle相反），第一张表会涉及到全表扫描，所以将小表放在前面，先扫小表，扫描快效率较高，在扫描后面的大表，或许只扫描大表的前100行就符合返回条件并return了。
例如：表1有50条数据，表2有30亿条数据；如果全表扫描表2，你品，那就先去吃个饭再说吧是吧。

4. 使用表的别名
当在SQL语句中连接多个表时，请使用表的别名并把别名前缀于每个列名上。这样就可以减少解析的时间并减少哪些友列名歧义引起的语法错误。

5. 用where字句替换HAVING字句
避免使用HAVING字句，因为HAVING只会在检索出所有记录之后才对结果集进行过滤，而where则是在聚合前刷选记录，如果能通过where字句限制记录的数目，那就能减少这方面的开销。HAVING中的条件一般用于聚合函数的过滤，除此之外，应该将条件写在where字句中。
where和having的区别：where后面不能使用组函数

6.调整Where字句中的连接顺序
MySQL采用从左往右，自上而下的顺序解析where子句。根据这个原理，应将过滤数据多的条件往前放，最快速度缩小结果集。


三、增删改 DML 语句优化
1. 大批量插入数据
Insert into T values(1,2),(1,3),(1,4); 
在特定场景可以减少对DB连接次数，SQL语句较短，可以减少网络传输的IO。

2. 适当使用commit
适当使用commit可以释放事务占用的资源而减少消耗，commit后能释放的资源如下：
事务占用的undo数据块；
事务在redo log中记录的数据块；
释放事务施加的，减少锁争用影响性能。特别是在需要使用delete删除大量数据的时候，必须分解删除量并定期commit。




delete和truncate的区别

1、在功能上，truncate是清空一个表的内容，它相当于delete from table_name。
2、delete是dml操作，truncate是ddl操作；因此，用delete删除整个表的数据时，会产生大量的roolback，占用很多的rollback segments， 而truncate不会。
3、在内存中，用delete删除数据，表空间中其被删除数据的表占用的空间还在，便于以后的使用，另外它是“假相”的删除，相当于windows中用delete删除数据是把数据放到回收站中，还可以恢复，当然如果这个时候重新启动系统（OS或者RDBMS），它也就不能恢复了！
而用truncate清除数据，内存中表空间中其被删除数据的表占用的空间会被立即释放，相当于windows中用shift+delete删除数据，不能够恢复！
4、truncate 调整high water mark 而delete不；truncate之后，TABLE的HWM退回到 INITIAL和NEXT的位置（默认）delete 则不可以。
5、truncate 只能对TABLE，delete 可以是table,view,synonym。
6、TRUNCATE TABLE 的对象必须是本模式下的，或者有drop any table的权限 而 DELETE 则是对象必须是本模式下的，或被授予 DELETE ON SCHEMA.TABLE 或DELETE ANY TABLE的权限。
7、在外层中，truncate或者delete后，其占用的空间都将释放。
8、truncate和delete只删除数据，而drop则删除整个表（结构和数据）。

区别

　　1.TRUNCATE TABLE是非常快的
　　2.TRUNCATE之后的自增字段从头开始计数了，而DELETE的仍保留原来的最大数值

　　TRUNCATE TABLE 在功能上与不带 WHERE 子句的 DELETE 语句相同：二者均删除表中的全部行。但 TRUNCATE TABLE 比 DELETE 速度快，且使用的系统和事务日志资源少。
DELETE 语句每次删除一行，并在事务日志中为所删除的每行记录一项。TRUNCATE TABLE 通过释放存储表数据所用的数据页来删除数据，并且只在事务日志中记录页的释放。
　　TRUNCATE TABLE 删除表中的所有行，但表结构及其列、约束、索引等保持不变。新行标识所用的计数值重置为该列的种子。如果想保留标识计数值，请改用 DELETE。如果要删除表定义及其数据，请使用 DROP TABLE 语句。
对于由 FOREIGN KEY 约束引用的表，不能使用 TRUNCATE TABLE，而应使用不带 WHERE 子句的 DELETE 语句。由于 TRUNCATE TABLE 不记录在日志中，所以它不能激活触发器。
　　TRUNCATE TABLE 不能用于参与了索引视图的表。

注意:这里说的delete是指不带where子句的delete语句

相同点
　　truncate和不带where子句的delete, 以及drop都会删除表内的数据

不同点:
\1. truncate和 delete只删除数据不删除表的结构(定义)
drop语句将删除表的结构被依赖的约束(constrain),触发器(trigger),索引(index); 依赖于该表的存储过程/函数将保留,但是变为invalid状态.
2.delete语句是dml,这个操作会放到rollback segement中,事务提交之后才生效;如果有相应的trigger,执行的时候将被触发.
truncate,drop是ddl, 操作立即生效,原数据不放到rollback segment中,不能回滚. 操作不触发trigger.
3.delete语句不影响表所占用的extent, 高水线(high watermark)保持原位置不动
显然drop语句将表所占用的空间全部释放
truncate 语句缺省情况下见空间释放到 minextents个 extent,除非使用reuse storage; truncate会将高水线复位(回到最开始).
4.速度,一般来说: drop>; truncate >; delete
5.安全性:小心使用drop 和truncate,尤其没有备份的时候.否则哭都来不及
使用上,想删除部分数据行用delete,注意带上where子句. 回滚段要足够大.
想删除表,当然用drop
想保留表而将所有数据删除. 如果和事务无关,用truncate即可. 如果和事务有关,或者想触发trigger,还是用delete.
如果是整理表内部的碎片,可以用truncate跟上reuse stroage,再重新导入/