sql查询优化_优化sql查询 - CSDN
精华内容
参与话题
  • sql查询时,查询同样的数据,有的sql写出来查询效率快,有的慢,为什么呢?
    展开全文
  • SQL查询优化

    2014-04-21 14:04:22
    转载地址:http://blog.csdn.net/songjuntao8/article/details/24195557

    转载地址:http://blog.csdn.net/songjuntao8/article/details/24195557

    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 子句中使用参数,也会导致全表扫描。因为SQL只有在运行时才会解析局部变量,但优化程序不能将访问计划的选择推迟到运行时;它必须在编译时进行选择。然而,如果在编译时建立访问计划,变量的值还是未知的,因而无法作为索引选择的输入项。如下面语句将进行全表扫描:
    select id from t where 
    num=@num
    可以改为强制查询使用索引: 
    select id from t with(index(索引名)) where 
    num=@num

    8.应尽量避免在 where 子句中对字段进行表达式操作,这将导致引擎放弃使用索引而进行全表扫描。如:
    select id from t where num/2=100 
    应改为: 
    select id from t where num=100*2

    9.应尽量避免在where子句中对字段进行函数操作,这将导致引擎放弃使用索引而进行全表扫描。如: 
    select id from t where substring(name,1,3)='abc'--name以abc开头的id 
    select id from t where datediff(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'

    10.不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算,否则系统将可能无法正确使用索引。

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

    12.不要写一些没有意义的查询,如需要生成一个空表结构: 
    select col1,col2 into #t from t where 1=0 
    这类代码不会返回任何结果集,但是会消耗系统资源的,应改成这样: 
    create table #t(...)

    13.很多时候用 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)

    14.并不是所有索引对查询都有效,SQL是根据表中数据来进行查询优化的,当索引列有大量数据重复时,SQL查询可能不会去利用索引,如一表中有字段sex,male、female几乎各一半,那么即使在sex上建了索引也对查询效率起不了作用。

    15.索引并不是越多越好,索引固然可以提高相应的 select 的效率,但同时也降低了 insert 及 update 的效率,因为 insert 或 update 时有可能会重建索引,所以怎样建索引需要慎重考虑,视具体情况而定。一个表的索引数最好不要超过6个,若太多则应考虑一些不常使用到的列上建的索引是否有必要。

    16.应尽可能的避免更新 clustered 索引数据列,因为 clustered 索引数据列的顺序就是表记录的物理存储顺序,一旦该列值改变将导致整个表记录的顺序的调整,会耗费相当大的资源。若应用系统需要频繁更新 clustered 索引数据列,那么需要考虑是否应将该索引建为 clustered 索引。

    17.尽量使用数字型字段,若只含数值信息的字段尽量不要设计为字符型,这会降低查询和连接的性能,并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符,而对于数字型而言只需要比较一次就够了。

    18.尽可能的使用 varchar/nvarchar 代替 char/nchar ,因为首先变长字段存储空间小,可以节省存储空间,其次对于查询来说,在一个相对较小的字段内搜索效率显然要高些。

    19.任何地方都不要使用 select * from t ,用具体的字段列表代替“*”,不要返回用不到的任何字段。

    20.尽量使用表变量来代替临时表。如果表变量包含大量数据,请注意索引非常有限(只有主键索引)。

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

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

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

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

    25.尽量避免使用游标,因为游标的效率较差,如果游标操作的数据超过1万行,那么就应该考虑改写。

    26.使用基于游标的方法或临时表方法之前,应先寻找基于集的解决方案来解决问题,基于集的方法通常更有效。

    27.与临时表一样,游标并不是不可使用。对小型数据集使用 FAST_FORWARD 游标通常要优于其他逐行处理方法,尤其是在必须引用几个表才能获得所需的数据时。在结果集中包括“合计”的例程通常要比使用游标执行的速度快。如果开发时间允许,基于游标的方法和基于集的方法都可以尝试一下,看哪一种方法的效果更好。

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

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

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


    展开全文
  • SQL Server查询优化(优化索引和查询)

    千次阅读 2018-09-07 13:57:07
    现在已经知道了哪些查询模式需要进行优化,可以着手更具体的查询优化步骤了。这一步会设计到索引优化查询代码优化SQL Server的数据库引擎顾问是一种工具。它可对输入的工作负荷进行分析,在此基础上为数据库...

    现在已经知道了哪些查询模式需要进行优化,可以着手更具体的查询优化步骤了。这一步会设计到索引优化和查询代码优化。

    SQL Server的数据库引擎顾问是一种工具。它可对输入的工作负荷进行分析,在此基础上为数据库优化提供建立。没有聚集索引的表被称为,拥有聚集索引的表叫聚集索引表(或聚集表)。

    索引是一种用于排序和搜索的结构。在查找数据库时,索引可以减少对I/O的消耗。

     

    页和区

    页是SQL Server存储数据的基本单元,大小为8KB。它可以包含表,索引,分配位图,可用空间信息等。页是SQL Server可以读写的最小I/O单元。即使只需访问一行, SQL Server也要把整个页加载到缓存,再从缓存中读取数据。对于基本数据操作所涉及的查询,其开销主要是I/O开销。

    区是由8个物理上连续的页组成的单元。当表或索引需要更多的空间存储数据时,SQL Server会为对象分配一个完整的区。对于包含少量数据的对象,有一个例外:如果对象不足64KB,则当需要更多的空间时,SQL Server通常分配一个单独的页,而不是整个区。

    表的组织方式

    表有两种组织方式:B。从技术上来说,当在表上创建一个聚集索引时,表就组织成一个B树;否则就组织成一个堆。所以表的组织方式也称为HOBT(Heap Or B Tree)。无论如何组织,表都可以定义0个或多个非聚集索引,而非聚集索引又会组织成B树。

    (heap)是不含聚集索引的表。它被称之为堆是由于它存储的数据不按照任何顺序组织,而是按分区对数据进行组织。在一个堆中,用于保存数据之间关系的唯一结构是一个索引分区映射(IAM,Index Allocation Map)的位图页。

    聚集索引

    SQL Server中所有的索引都组织为B结构,B树是平衡树的一种特例。平衡树的定义是“不存在叶子节点比其他叶子节点到根的距离要远的多的树”。它在叶子节点中维护整个表的所有数据。聚集索引不是数据的副本,而是数据本身。

    当SQL Server需要对索引的页层执行无需扫描时,可以使用IAM页,这种扫描称为分配顺序扫描(allocation order scan)。而按照索引顺序完成的扫描称为索引顺序扫描(index order scan)。如果索引的碎片级别较高,则顺序扫描要慢得多。

    当SQL Server需要导航到位于叶级的特定键时,它总是从根页开始,使用一种称为索引查找(index seek)的访问方法。这些读操作的I/O称为随机I/O,其读取次数和索引级别是一样多的。

     

    堆上的非聚集索引

    非聚集索引也结构化为一颗B树,而且在许多方面都和聚集索引类似。唯一的区别是非聚集索引的叶级行只包含索引键和特定的行定位符(row locator)。行定位符它是一个8字节的物理指针(RID),它由数据库中文件号,文件中的目标页号,目标页的行号组成。因此SQL Server必须在查找操作之后,执行一个RID的查找操作,对于大量的数据而言,开销会非常高。

    聚集表上的非聚集索引

    在聚集表上创建的非聚集索引和在堆上创建的非聚集索引,唯一的区别是:前者的行定位符是一个称为聚集键的值,而不是RID。其原理是指向逻辑的行,而不是物理的行。

     

    展开全文
  • SQL查询速度优化

    千次阅读 2018-10-23 13:49:39
    多表使用left join只是把主表里的所有数据查询出来,其他表只查询表中的符合条件的某一条记录,所以速度非常快;而多表使用where内联,是把所有表的数据全查出来,然后进行比对,所以速度非常慢。 使用left join要...

    1、使用left join比直接使用where速度快

    参考:使用left join比直接使用where速度快的原因

    多表使用left join只是把主表里的所有数据查询出来,其他表只查询表中的符合条件的某一条记录,所以速度非常快;而多表使用where内联,是把所有表的数据全查出来,然后进行比对,所以速度非常慢。

    使用left join要注意确定哪一张表是主表,如果无法确定主表,则选择哪张表查询的字段最多,就把哪张表作为主表。

    示例如下:

    使用left join,同样的数据量,时间不到1秒钟!

    SELECT a.projectno,MAX(a.projectname) projectname,max(a.projectMoney) projectMoney,
    max(a.projectLimitYear) projectLimitYear,max(a.monthcharge) monthcharge,
    max(c.orgname) orgname,max(d.businesstypename) businesstypename,max(e.name) name,
    max(b.dicvalue) dicvalue,
    min(CONVERT(varchar(100),DATEADD("DAY",jbl.DelayDays,jbl.ReportTime),23)) as period,
    max(f.fiveleveltype) fiveleveltype,max(a.ProjectInfoId) ProjectInfoId,
    max(g.FlowRunId) FlowRunId
    FROM
    (select ProjectInfoId,ProjectNo,Status,OrgId,TypeID,UserAId,IsDelete,ProjectName,ProjectMoney,ProjectLimitYear,MonthCharge from jt_biz_projectinfo) a
    LEFT JOIN
    (select b.* from (select MAX(id) id, ProjectNo from JT_Biz_Lecture group by ProjectNo) a,
    JT_Biz_Lecture b where a.id=b.id) f
    on a.projectno=f.projectno
    LEFT JOIN
    (select DicId,IsDelete,DicValue,DicCode from jt_Base_Dictionary) b
    ON a.status=b.dicId
    LEFT JOIN
    (select ProjectNo,DelayDays,ReportTime from Jt_Biz_LectureTemp) jbl
    ON a.projectno=jbl.projectno
    LEFT JOIN
    (select IsDelete,OrgName,OrgId from jt_base_org) c
    ON a.orgid=c.orgid
    LEFT JOIN
    (select ID,BusinessTypeName from d_businesstype) d
    ON a.typeid=d.id
    LEFT JOIN
    (select UserInfoId,IsDelete,Name,UserName from jt_base_userInfo) e
    ON a.useraid=e.userinfoid
    LEFT JOIN
    (select UserId,PostId,OrgIds from JT_Base_Post_UserOrg) j
    ON j.UserId=e.userinfoid
    LEFT JOIN
    (select PostId from JT_Base_Post) k
    ON j.PostId=k.PostId
    LEFT JOIN
    (select FlowRunId,ProjectId from jt_flow_run) g
    ON a.ProjectInfoId=g.ProjectId
    LEFT JOIN
    (select FlowRunId from JT_Flow_Run_Prcs) h
    ON g.FlowRunId = h.FlowRunId
    LEFT JOIN
    (select OrgId,OrgName from JT_Base_Org) l
    ON a.OrgId=l.OrgId
    WHERE a.status in(82,83,84) and a.isdelete=0
    and b.isdelete=0 and c.isdelete=0 and e.isdelete=0
    and (l.OrgId in(null) or e.UserName='chenqf') group by a.ProjectNo;
    不使用left join,同样数据量,时间大概在50秒的样子!
    select a.projectno,max(a.projectname) projectname,max(a.projectMoney) projectMoney,
    max(a.projectLimitYear) projectLimitYear,max(a.monthcharge) monthcharge,
    max(c.orgname) orgname,max(d.businesstypename) businesstypename,max(e.name) name,
    max(b.dicvalue) dicvalue,
    min(CONVERT(varchar(100),DATEADD("DAY",jbl.DelayDays,jbl.ReportTime),23)) as period,
    max(f.fiveleveltype) fiveleveltype,max(a.ProjectInfoId) ProjectInfoId,
    max(g.FlowRunId) FlowRunId
    from (select DicId,IsDelete,DicValue,DicCode from jt_Base_Dictionary) b,
    (select IsDelete,OrgName,OrgId from jt_base_org) c,
    (select UserInfoId,IsDelete,Name,UserName from jt_base_userInfo) e,
    (select ID,BusinessTypeName from d_businesstype) d,
    (select FlowRunId,ProjectId from jt_flow_run) g,
    (select FlowRunId from JT_Flow_Run_Prcs) h,
    (select UserId,PostId,OrgIds from JT_Base_Post_UserOrg) j,
    (select PostId from JT_Base_Post) k,
    (select OrgId,OrgName from JT_Base_Org) l,
    (select ProjectNo,DelayDays,ReportTime from Jt_Biz_LectureTemp) jbl,
    (select ProjectInfoId,ProjectNo,Status,OrgId,TypeID,UserAId,IsDelete,ProjectName,ProjectMoney,ProjectLimitYear,MonthCharge from jt_biz_projectinfo) a
    left join
    (select b.* from (select MAX(id) id, ProjectNo from JT_Biz_Lecture group by ProjectNo) a,
    JT_Biz_Lecture b where a.id=b.id) f
    on a.projectno=f.projectno where a.status=b.dicId and a.status in(82,83,84)
    and a.projectno=jbl.projectno and a.orgid=c.orgid and a.typeid=d.id
    and a.useraid=e.userinfoid and j.UserId=e.userinfoid and a.isdelete=0
    and b.isdelete=0 and c.isdelete=0 and e.isdelete=0 and g.FlowRunId = h.FlowRunId 
    and (l.OrgId in(null) or e.UserName='chenqf')
    group by a.ProjectNo;

    2、LEFT JOIN关联表中ON,WHERE后面跟条件的区别

    写SQL本想通过 A left join B on and 后面的条件来使查出的两条记录变成一条,奈何发现还是有两条。

    后来发现  on and 不会过滤结果记录条数,只会根据and后的条件是否显示 B表的记录,A表的记录一定会显示。

    不管and 后面的是A.id=1还是B.id=1,都显示出A表中所有的记录,并关联显示B中对应A表中id为1的记录或者B表中id为1的记录。

    运行sql : select * from student s left join class c on s.classId=c.id order by s.id

    运行sql : select * from student s left join class c on s.classId=c.id and s.name="张三" order by s.id


    运行sql : select * from student s left join class c on s.classId=c.id and c.name="三年级三班" order by s.id

           通过查询相关资料了解到:

           数据库在通过连接两张或多张表来返回记录时,都会生成一张中间的临时表,然后再将这张临时表返回给用户。

          在使用left jion时,on和where条件的区别如下:

    1、 on条件是在生成临时表时使用的条件,它不管on中的条件是否为真,都会返回左边表中的记录。

    2、where条件是在临时表生成好后,再对临时表进行过滤的条件。这时已经没有left join的含义(必须返回左边表的记录)了,条件不为真的就全部过滤掉。

           假设有两张表:

    表1:tab1

    表2:tab2

    两条SQL:
    1、select * form tab1 left join tab2 on (tab1.size = tab2.size) where tab2.name=’AAA’
    2、select * form tab1 left join tab2 on (tab1.size = tab2.size and tab2.name=’AAA’)

        

         其实以上结果的关键原因就是left join,right join,full join的特殊性,不管on上的条件是否为真都会返回left或right表中的记录,full则具有left和right的特性的并集。 而inner jion没这个特殊性,则条件放在on中和where中,返回的结果集是相同的。

    3、Where条件中使用主表条件过滤速度较快

    
    		SELECT
           *
    		FROM
    			USER_BORROW T1   -- 数据量2~3万条
    		LEFT JOIN USER T3 ON T3.OID_USER_ID = T1.OID_USER_ID
    		LEFT JOIN USER_DETAIL T4 ON T4.OID_USER_ID = T1.OID_USER_ID
    		LEFT JOIN USER_ARCHIVES T5 ON T5.OID_ARCHIVE_ID = T1.OID_ARCHIVE_ID    -- USER_ARCHIVES数据量2~3万条
    		LEFT JOIN PRODUCT_MST T6 ON T6.OID_PROD_ID = T5.OID_PROD_ID
    		LEFT JOIN TENANT T7 ON T7.OID_TENANT_ID = T5.OID_TENANT_ID
    		LEFT JOIN TENANT T8 ON T8.OID_TENANT_ID = T5.OID_TENANT_XS_ID
    		LEFT JOIN (
    			SELECT
    				OID_BORROW_ID,
    				SUM(REPAY_AMOUNT_TOTAL) AS FEE_AMOUNT
    			FROM
    				USER_POUNDAGE_REPAY
    			WHERE
    				REPAY_FLG = '0'
    			GROUP BY
    				OID_BORROW_ID
    		) T9 ON T1.BORROW_ID = T9.OID_BORROW_ID
    		WHERE
    			1 = 1
         -- 此处使用T1.OID_TENANT_ID进行数据过滤查询速度很快,
         -- 但是使用T5.OID_TENANT_ID进行过滤数据查询速度极慢,不确定是否跟T1为主表有关系???
    		AND T1.OID_TENANT_ID IN (  
    			SELECT
    				OT.OID_TENANT_ID
    			FROM
    				DEPARTMENT_USER DU
    			INNER JOIN OPERATOR_TENANT OT ON OT.OID_OPERATOR_USER_ID = DU.OID_ADMIN_USER_ID
    			WHERE
    				DU.DEL_FLG = '0'
    			AND DU.OID_DEPARTMENT_ID = (
    				SELECT
    					DU1.OID_DEPARTMENT_ID
    				FROM
    					DEPARTMENT_USER DU1
    				WHERE
    					DU1.OID_ADMIN_USER_ID = ?
    				AND DU1.DEL_FLG = '0'
    			)
    		)
    	

     

    展开全文
  • 下面是网络中流传最广的一篇sql查询速度慢的原因及解决方法的文章,其对于处理mysql的慢查询有借鉴作用。由于此文转载多次,很难找到最开始的原文链接,就附送本人最先看到此文的链接:...
  • sql server 性能优化

    千次阅读 2019-04-15 17:06:16
    1、 用程序中,保证在实现...在数据窗口使用SQL时,尽量把使用的索引放在选择的首列;  算法的结构尽量简单;在查询时,不要过多地使用通配符如SELECT * FROM T1语句,要用到几列就选择几列如:SELECT COL1,COL2 F...
  • sql优化的几种方式

    万次阅读 多人点赞 2019-11-11 09:15:50
    一、为什么要对SQL进行优化 我们开发项目上线初期,由于业务数据量相对较少,一些SQL的执行效率对程序运行效率的影响不太明显,而开发和运维人员也...二、SQL优化的一些方法 1.对查询进行优化,应尽量避免全表扫描...
  • sql 查询优化

    2019-03-14 14:59:29
    1、对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引。 2、应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如:  select...
  • DBA的五款优秀SQL查询优化工具

    千次阅读 2019-07-30 11:00:33
    一般来说,SQL查询优化器分析给定查询的许多选项,预估每个选项的成本,最后选择成本最低的选项。如果查询优化器选择了错误的计划,则性能差异可能从几毫秒到几分钟。幸运的是,现在有许多第...
  • MYSQL性能优化SQL查询优化

    千次阅读 2017-06-24 10:39:17
    SQL查询优化目的:减少查询所消耗的时间,加快查询的相应速度 获取有性能问题的SQL查询日志开销比较低 磁盘IO (顺序存储) 开销忽略不计 存储日志大小所需要的磁盘空间 (依赖) 控制sql配置 - slow_query_log...
  • SQL查询优化工具--EverSQL

    千次阅读 2020-03-20 16:22:57
    EverSQ是L一款免费的、开源的、在线SQL查询优化工具。EverSQL提供了监控SQL查询性能的最简单方法,具有以下功能: 轻松优化SQL查询 简单易用 配有直观的界面 无需下载或安装。 只需上传或输入查询,上传架构并获得...
  • 高mysql千万级大数据SQL查询优化几条经验
  • Oracle SQL查询优化方法1

    千次阅读 2017-04-18 14:51:45
    系统优化中很重要的方面是SQL语句的优化,对于海量数据,优质的SQL能够有效的提高系统的可用性。 总结的有点罗嗦,列个简单的目录啦~ 目录 ...第一部分 知识准备 第二部分 ... 第三部分 sql优化总结  1. sql
  • 本文主要内容:1:查询语句where 子句使用时候优化或者需要注意的2:like语句使用时候需要注意3:in语句代替语句4:索引使用或是创建需要注意假设用户表有一百万用户量。也就是1000000.num是主键1:对查询进行优化,...
  • 百万级别数据查询SQL查询优化

    千次阅读 2019-05-28 17:43:44
    针对近期项目中遇到的大数据查询进行总结。 这篇文章花费了我大量的时间,通过网上查找资料和自己的总结归纳,如有不当,请大家指正: 1.在大数据查询中要避免like模糊查询,在进行模糊查询时会进行多次全表遍历,...
  • sql查询优化

    万次阅读 2017-07-18 09:44:23
    浅析sql查询优化开门见山,结合笔者工作中处理过的问题,以及前人的经验,总结几点有关sql查询优化时的注意问题。不完善之处还望多多指正。一、 避免全表扫描 全表扫描往往是由索引失效造成,那么什么情况下会造成...
  • explain可以帮助我们分析select语句,找出select语句的瓶颈,从而可以针对性地去做优化,让MySQL查询优化器更好地工作。 MySQL查询优化器有几个目标,其中最主要的目标是尽可能地使用索引,并且使用最严格的索引来...
  • sql优化的几种方法

    万次阅读 多人点赞 2017-08-17 20:59:55
    在sql查询中为了提高查询效率,我们常常会采取一些措施对查询语句进行sql优化,下面总结的一些方法,有需要的可以参考参考。 1.对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上...
  • 一、SQL查询优化(重要) 1.1 获取有性能问题SQL的三种方式 通过用户反馈获取存在性能问题的SQL; 通过慢查日志获取存在性能问题的SQL; 实时获取存在性能问题的SQL; 1.1.2 慢查日志分析工具 相关配置参数: ...
  • mysql千万级大数据SQL查询优化

    万次阅读 多人点赞 2016-07-29 13:27:31
    1.对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引。 2.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如:select ...
1 2 3 4 5 ... 20
收藏数 419,528
精华内容 167,811
关键字:

sql查询优化