[转] 大数据量惯用优化方法

尊重知识,尊重作者。原文链接:http://www.thebigdata.cn/JieJueFangAn/14134.html
在大数据网站看到的,方便日后查用转来保存。

  1. 应尽量避免在 where 子句中对字段进行 null值判断,否则将导致引擎放弃使用索引而进行全表扫描,如:

  select id from t where num is null

  可以在num上设置默认值0,确保表中num列没有null值,然后这样查询:

  select id from t where num=0

  2. 应尽量避免在 where 子句中使用!=或<>操作符,否则将导致引擎放弃使用索引而进行全表扫描。优化器将无法通过索引来确定将要命中的行数,因此需要搜索该表的所有行。

  3. 应尽量避免在 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

  4. in和 not in也要慎用,因为in会使系统无法使用索引,而只能直接搜索表中的数据。如:

  select id from t where num in(1,2,3)

  对于连续的数值,能用 between就不要用 in了:

  select id from t where num between 1 and 3

  5. 尽量避免在索引过的字符数据中,使用非字母打头搜索。这也使得引擎无法利用索引。 见如下例子:

  SELECT * FROM T1 WHERE NAME LIKE‘%L%’

  SELECT * FROM T1 WHERE SUBSTING(NAME,2,1)=’L’

  SELECT * FROM T1 WHERE NAME LIKE‘L%’

  即使NAME字段建有索引,前两个查询依然无法利用索引完成加快操作,引擎不得不对全表所有数据逐条操作来完成任务。而第三个查询能够使用索引来加快操作。

  6. 必要时强制查询优化器使用某个索引,如在 where 子句中使用参数,也会导致全表扫描。因为SQL只有在运行时才会解析局部变量,但优化程序不能将访问计划的选择推迟到运行时;它必须在编译时进行选择。然而,如果在编译时建立访问计划,变量的值还是未知的,因而无法作为索引选择的输入项。如下面语句将进行全表扫描:

  select id from t where

  可以改为强制查询使用索引:

  select id from t with(index(索引名)) where

  7. 应尽量避免在 where 子句中对字段进行表达式操作,这将导致引擎放弃使用索引而进行全表扫描。如:

  SELECT* FROM T1 WHERE F1/2=100

  应改为:

  SELECT* FROM T1 WHERE F1=100*2

  SELECT *FROM RECORD WHERESUBSTRING(CARD_NO,1,4)=’5378’

  应改为:

  SELECT *FROM RECORD WHERE CARD_NO LIKE ‘5378%’

  SELECTmember_number,first_name,last_name FROM members

  WHEREDATEDIFF(yy,datofbirth,GETDATE())> 21

  应改为:

  SELECTmember_number,first_name,last_name FROM members

  WHEREdateofbirth

  即:任何对列的操作都将导致表扫描,它包括数据库函数、计算表达式等等,查询时要尽可能将操作移至等号右边。

  8. 应尽量避免在where子句中对字段进行函数操作,这将导致引擎放弃使用索引而进行全表扫描。如:

  select id from t where substring(name,1,3)=‘abc‘—name

  以abc开头的id

  select id from t wheredatediff(day,createdate,‘2005-11-30‘)=0--‘2005-11-30’

  生成的id

  应改为:

  select id from t where name like ‘abc%‘

  select id from t where createdate>=‘2005-11-30‘and createdate<‘2005-12-1‘

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

  10. 很多时候用 exists是一个好的选择:

  selectnum from a where num in(select num from b)

  用下面的语句替换:

  select num from a where exists(select 1 from b where num=a.num)

  SELECT SUM(T1.C1)FROM T1 WHERE(

  (SELECT COUNT(*)FROM T2 WHERE T2.C2=T1.C2>0)

  SELECT SUM(T1.C1) FROM T1WHERE EXISTS(

  SELECT *FROM T2 WHERE T2.C2=T1.C2)

  两者产生相同的结果,但是后者的效率显然要高于前者。因为后者不会产生大量锁定的表扫描或是索引扫描。

  如果你想校验表里是否存在某条纪录,不要用count(*)那样效率很低,而且浪费服务器资源。可以用EXISTS代替。如:

  IF (SELECT COUNT(*)FROM table_name WHERE column_name= ‘xxx‘)

  可以写成:

  IF EXISTS (SELECT * FROM table_name WHERE column_name =‘xxx‘)

  经常需要写一个T_SQL语句比较一个父结果集和子结果集,从而找到是否存在在父结果集中有而在子结果集中没有的记录,如:

  SELECT a.hdr_key FROM hdr_tbl a----tbla表示tbl用别名a代替

  WHERE NOT EXISTS (SELECT * FROM dtl_tbl b WHERE a.hdr_key =b.hdr_key)

  SELECT a.hdr_key FROM hdr_tbla

  LEFT JOIN dtl_tbl b ON a.hdr_key=b.hdr_key WHERE b.hdr_key IS NULL

  SELECT hdr_key FROM hdr_tbl

  WHERE hdr_key NOT IN (SELECThdr_keyFROMdtl_tbl)

  三种写法都可以得到同样正确的结果,但是效率依次降低。

  11. 避免频繁创建和删除临时表,以减少系统表资源的消耗。

  12. 临时表并不是不可使用,适当地使用它们可以使某些例程更有效,例如,当需要重复引用大型表或常用表中的某个数据集时。但是,对于一次性事件,最好使用导出表。

  13. 在新建临时表时,如果一次性插入数据量很大,那么可以使用 select into 代替 create table,避免造成大量 log ,以提高速度;如果数据量不大,为了缓和系统表的资源,应先create table,然后insert。

  14. 如果使用到了临时表,在存储过程的最后务必将所有的临时表显式删除,先 truncate table ,然后 drop table,这样可以避免系统表的较长时间锁定。

  15. 在所有的存储过程和触发器的开始处设置 SET NOCOUNT ON ,在结束时设置 SET NOCOUNT OFF。无需在执行存储过程和触发器的每个语句后向客户端发送 DONE_IN_PROC消息。

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

  17. 尽量避免向客户端返回大数据量,若数据量过大,应该考虑相应需求是否合理,比如是否返回全对象,可不可以减少某些非必要字段。

  18.避免使用不兼容的数据类型。例如float和int、char和varchar、binary和varbinary是不兼容的。数据类型的不兼容可能使优化器无法执行一些本来可以进行的优化操作。例如:

  SELECT name FROM employee WHERE salary >60000

  在这条语句中,如salary字段是money型的,则优化器很难对其进行优化,因为60000是个整型数。我们应当在编程时将整型转化成为钱币型,而不要等到运行时转化。

  19. 充分利用连接条件,在某种情况下,两个表之间可能不只一个的连接条件,这时在 WHERE 子句中将连接条件完整的写上,有可能大大提高查询速度。 例:

  SELECTSUM(A.AMOUNT) FROM ACCOUNT A, CARD B WHERE A.CARD_NO =B.CARD_NO

  SELECTSUM(A.AMOUNT) FROM ACCOUNT A,CARD B WHERE A.CARD_NO =B.CARD_NO AND A.ACCOUNT_NO=B.ACCOUNT_NO

  第二句将比第一句执行快得多。

  20. 使用视图加速查询 把表的一个子集进行排序并创建视图,有时能加速查询。它有助于避免多重排序操作,而且在其他方面还能简化优化器的工作。

  21. 能用DISTINCT的就不用GROUP BY

  SELECTOrderIDFROM Details WHEREUnitPrice > 10 GROUP BYOrderID

  可改为:

  SELECT DISTINCTOrderIDFROM Details WHEREUnitPrice > 10

  22. 能用UNION ALL就不要用UNION UNIONALL不执行SELECT DISTINCT函数,这样就会减少很多不必要的资源

  23. 尽量不要用SELECT INTO语句。 SELECT INOT语句会导致表锁定,阻止其他用户访问该表。
时间: 2024-10-12 15:03:30

[转] 大数据量惯用优化方法的相关文章

MySQL 大数据量快速插入方法和语句优化

MySQL大数据量快速插入方法和语句优化是本文我们主要要介绍的内容,接下来我们就来一一介绍,希望能够让您有所收获! INSERT语句的速度 插入一个记录需要的时间由下列因素组成,其中的数字表示大约比例: 连接:(3) 发送查询给服务器:(2) 分析查询:(2) 插入记录:(1x记录大小) 插入索引:(1x索引) 关闭:(1) 这不考虑打开表的初始开销,每个并发运行的查询打开. 表的大小以logN (B树)的速度减慢索引的插入. 加快插入的一些方法 如果同时从同一个客户端插入很多行,使用含多个VA

MySQL大数据量分页查询方法及其优化

方法1: 直接使用数据库提供的SQL语句 语句样式: MySQL中,可用如下方法: SELECT * FROM 表名称 LIMIT M,N 适应场景: 适用于数据量较少的情况(元组百/千级) 原因/缺点: 全表扫描,速度会很慢 且 有的数据库结果集返回不稳定(如某次返回1,2,3,另外的一次返回2,1,3). Limit限制的是从结果集的M位置处取出N条输出,其余抛弃. 方法2: 建立主键或唯一索引, 利用索引(假设每页10条) 语句样式: MySQL中,可用如下方法: SELECT * FRO

大数据量数据库优化 - CodeMain - 博客园

一.数据库结构的设计 如果不能设计一个合理的数据库模型,不仅会增加客户端和服务器段程序的编程和维护的难度,而且将会影响系统实际运行的性能.所以,在一个系统开始实施之前,完备的数据库模型的设计是必须的. 在一个系统分析.设计阶段,因为数据量较小,负荷较低.我们往往只注意到功能的实现,而很难注意到性能的薄弱之处,等到系统投入实际运行一段时间后,才发现系统的性能在降低,这时再来考虑提高系统性能则要花费更多的人力物力,而整个系统也不可避免的形成了一个打补丁工程. 所以在考虑整个系统的流程的时候,我们必须

大数据量数据库优化

一.数据库结构的设计 如果不能设计一个合理的数据库模型,不仅会增加客户端和服务器段程序的编程和维护的难度,而且将会影响系统实际运行的性能.所以,在一个系统开始实施之前,完备的数据库模型的设计是必须的. 在一个系统分析.设计阶段,因为数据量较小,负荷较低.我们往往只注意到功能的实现,而很难注意到性能的薄弱之处,等到系统投入实际运行一段时间后,才发现系统的性能在降低,这时再来考虑提高系统性能则要花费更多的人力物力,而整个系统也不可避免的形成了一个打补丁工程. 所以在考虑整个系统的流程的时候,我们必须

Mysql大数据量分页优化

假设有一个千万量级的表,取1到10条数据: select * from table limit 0,10; select * from table limit 1000,10; 这两条语句查询时间应该在毫秒级完成: select * from table limit 3000000,10; 你可能没想到,这条语句执行之间在5s左右: 为什么相差这么大? 可能mysql并没有你想的那么智能,比如你要查询 300w开始后面10条数据:mysql会读取300w加10条这么多的数据,只不过 过滤后返回最

mysql大数据量下优化

1 优化sql和索引2 增加缓存如:redis3 主从复制或主主复制,读写分离4 利用mysql自带分区表5 先做垂直拆分,将一个大系统分为多个小系统,也就是分布式6 水平切分,要选择一个合理的sharding key,为了有好的查询效率,表结构也要改动,做一定的冗余,应用也要改,sql中尽量带sharding key,将数据定位到限定的表上去查,而不是扫描全部的表 参考:https://www.cnblogs.com/nengka/p/mysqloptimization.html 原文地址:h

大数据量高并发访问的数据库优化方法

一.数据库结构的设计 如果不能设计一个合理的数据库模型,不仅会增加客户端和服务器段程序的编程和维护的难度,而且将会影响系统实际运行的性能.所以,在一个系统开始实施之前,完备的数据库模型的设计是必须的. 在一个系统分析.设计阶段,因为数据量较小,负荷较低.我们往往只注意到功能的实现,而很难注意到性能的薄弱之处,等到系统投入实际运行一段时间后,才发现系统的性能在降低,这时再来考虑提高系统性能则要花费更多的人力物力,而整个系统也不可避免的形成了一个打补丁工程. 所以在考虑整个系统的流程的时候,我们必须

大数据量高并发訪问的数据库优化方法

????假设不能设计一个合理的数据库模型.不仅会添加client和server段程序的编程和维护的难度,并且将会影响系统实际运行的性能.所以,在一个系统開始实施之前,完备的数据库模型的设计是必须的. ????在一个系统分析.设计阶段.由于数据量较小.负荷较低.我们往往仅仅注意到功能的实现.而非常难注意到性能的薄弱之处,等到系统投入实际运行一段时间后,才发现系统的性能在降低.这时再来考虑提高系统性能则要花费很多其它的人力物力,而整个系统也不可避免的形成了一个打补丁project. ????所以在考

MySQL随机获取数据的方法,支持大数据量

最近做项目,需要做一个从mysql数据库中随机取几条数据出来. 总所周知,order by rand 会死人的..因为本人对大数据量方面的只是了解的很少,无解,去找百度老师..搜索结果千篇一律.特发到这里来,供大家学习. 在mysql中带了随机取数据的函数,在mysql中我们会有rand()函数,很多朋友都会直接使用,如果几百条数据肯定没事,如果几万或百万时你会发现,直接使用是错误的.下面我来介绍随机取数据一些优化方法. SELECT * FROM table_name ORDER BY ran