sql查询的优化
A. 【DB2】sql优化
于我来说,我喜欢技术,不偏执于某一类开发语言,愿意花时间精力去解决问题。
1.去除在谓词列上编写的任何标量函数
优化前:(耗时3.1s)
优化后:(耗时0.922s)
总结:
DB2可以选择使用START_DATE上的列索引,但是在列上使用了函数后,DB2就无法使用列索引了,从而导致查询效率变低。
2.去除在谓词列上编写的任何数学运算
优化前:(耗时10.265)
优化后:(耗时3.39s)
总结:
DB2查询时候,会优先选择列CONTRACT_AMT上的索引,如果直接对列CONTRACT_AMT应用数学运算,DB2就无法使用索引了。一定要做到:列本身(不加数学运算)放在操作符的一边,而所有的计算都放在另外一边。
3.SQL语句中指定查询列
优化前:(耗时13.15s)
优化后:(耗时2.922s)
总结:
如果Select包含不需要的列,优化工具会选择Indexonly=’N’,这会强制DB2必须进入数据页来得到所请求的特定列,这就要求更多的I/O操作,梁歪,这些多余的列可能是某些排序的部分,这样一来就需要和传递一个更大的排序文件,相应的会使排序成本更高。
4.尽可能不使用distinct
优化前:(耗时0.687s)
优化后:(耗时0.437s)
总结:
在测试distinct与group by性能的过程中,在列CST_ID上添加索引后,发现group by 确实比distinct快一些,但是在数据分布比较离散的情况下使用group by ,比较集中的情况下使用distinct.表数据量较少的情况随便使用哪个都一样, 不管选择谁,都要建立索引
5.Exists、in、not in 、not exists的使用场景选择
5.1 in跟exists的区别:
例如:表A(小表),表B(大表)
优化前:(耗时1.93s)
优化后:(耗时1.125s)
相反的,
优化前:(耗时1.9s)
优化后:(耗时1.0s)
总结:
in是把外表和内表作hash连接,而exists是对外表作loop循环,每次loop循环再对内表进行查询,一直以来认为exists比in效率高的说法是不准确的。 如果查询的两个表大小相当,那么用in和exists差别不大;如果两个表中一个较小一个较大,则子查询表大的用exists,子查询表小的用in;
简称:子大Exists,子小in
5.2 not in 与 not exists区别:
如果查询语句使用了not in,那么对内外表都进行全表扫描,没有用到索引;而not exists的子查询依然能用到表上的索引。所以无论哪个表大,用not exists都比not in 要快。
6.尽可能使用union all来代替union
优化前:(耗时15.344s)
优化后:(耗时2.719s)
总结:
在union中,DB2最后会自动执行一个排序来消除重复值,这样是很耗费资源的,所以在不需要去重复的情况下,尽可能使用UNION ALL 代替union
N.模板
优化前:(耗时3.1s)
优化后:(耗时0.922s)
总结:
B. sql语句查询,多字段like模糊查询优化
1、多字段like模糊查询优化:
最常见的写法:
where a like '%xx%' or b like '%xx%' or c like '%xx%';
这种写法查询效率低,经过调查,下面的方法可以替代,并且效率高:
2、如果like的关键字相同:
where instr(nvl(a, '')||nvl(b,'')||nvl(c,''), 'xx') > 0
把要模糊查询的字段先拼接起来,拼接时需要把null转成‘’,否则只要有一个字段值是空,整个拼接的字符串都成空了, 然后用instr 函数去过滤;
3、如果like的关键字不同:
where instr(a, 'xx') > 0 or instr(b, 'yy') > 0 or instr(c, 'zz') > 0
经过测试,这两种方法都比like效率要高;
C. SQL语句的几种优化方法
1、尽可能建立索引,包括条件列,连接列,外键列等。
2、尽可能让where中的列顺序与复合索引的列顺序一致。
3、尽可能不要select *,而只列出自己需要的字段列表。
4、尽可能减少子查询的层数。
5、尽可能在子查询中进行数据筛选 。
D. SQL数据库优化的方法有哪些
在进行软件开发过程中,数据库的使用是非常重要的,但是数据库有很多种,不同数据库的使用方法是不同的。进行软件开发过程中,至少需要掌握一种数据库的使用方法。SQL数据库语法简单、操作方便和高效,是很多人最优的选择,但是SQL语句会受到不同数据库功能的影响,在计算时间和语言的效率上面需要进行优化,根据实际情况进行调整。下面电脑培训为大家介绍SQL数据库的优化方法。
一、适当的索引
索引基本上是一种数据结构,有助于加速整个数据检索过程。唯一索引是创建不重叠的数据列的索引。正确的索引可以更快地访问数据库,但是索引太多或没有索引会导致错误的结果。IT培训认为如果没有索引,处理速度会变得非常慢。
二、仅索引相关数据
指定需要检索数据的精度。使用命令*和LIMIT代替SELECT*。调整数据库时,必须使用所需的数据集而不是整个数据集,尤其是当数据源非常大时,指定所需的数据集,能够节省大部分时间。
三、根据需求使用或避免临时表
如果代码可以用简单的方式编写,那么永远不要使临时表变得复杂。当然,如果数据具有需要多个查询的特定程序,北大青鸟建议在这种情况下,使用临时表。临时表通常由子查询交替。
四、避免编码循环
避免编码循环是非常重要的,因为它会减慢整个序列的速度。通过使用具有单行的唯一UPDATE或INSERT命令来避免编码循环,并且昆明北大青鸟发现WHERE命令能够确保存储的数据不被更新,这样能够方便在找到匹配和预先存在的数据时被找到。
E. SQL优化万能公式:5 大步骤 + 10 个案例
在应用开发的早期,数据量少,开发人员开发功能时更重视功能上的实现,随着生产数据的增长,很多SQL语句开始暴露出性能问题,对生产的影响也越来越大,有时可能这些有问题的SQL就是整个系统性能的瓶颈。
1、通过慢查日志等定位那些执行效率较低的SQL语句
2、explain 分析SQL的执行计划
type由上至下,效率越来越高
Extra
3、show profile 分析
了解SQL执行的线程的状态及消耗的时间。默认是关闭的,开启语句“set profiling = 1;”
4、trace
trace分析优化器如何选择执行计划,通过trace文件能够进一步了解为什么优惠券选择A执行计划而不选择B执行计划。
5、确定问题并采用相应的措施
案例1、最左匹配
索引
SQL语句
查询匹配从左往右匹配,要使用order_no走索引,必须查询条件携带shop_id或者索引( shop_id , order_no )调换前后顺序
案例2、隐式转换
索引
SQL语句
隐式转换相当于在索引上做运算,会让索引失效。mobile是字符类型,使用了数字,应该使用字符串匹配,否则MySQL会用到隐式替换,导致索引失效。
案例3、大分页
索引
SQL语句
对于大分页的场景,可以优先让产品优化需求,如果没有优化的,有如下两种优化方式, 一种是把上一次的最后一条数据,也即上面的c传过来,然后做“c < xxx”处理,但是这种一般需要改接口协议,并不一定可行。另一种是采用延迟关联的方式进行处理,减少SQL回表,但是要记得索引需要完全覆盖才有效果,SQL改动如下
案例4、in + order by
索引
SQL语句
in查询在MySQL底层是通过n*m的方式去搜索,类似union,但是效率比union高。in查询在进行cost代价计算时(代价 = 元组数 * IO平均值),是通过将in包含的数值,一条条去查询获取元组数的,因此这个计算过程会比较的慢,所以MySQL设置了个临界值(eq_range_index_pe_limit),5.6之后超过这个临界值后该列的cost就不参与计算了。因此会导致执行计划选择不准确。默认是200,即in条件超过了200个数据,会导致in的代价计算存在问题,可能会导致Mysql选择的索引不准确。
处理方式,可以( order_status , created_at )互换前后顺序,并且调整SQL为延迟关联。
案例5、范围查询阻断,后续字段不能走索引
索引
SQL语句
范围查询还有“IN、between”
案例6、不等于、不包含不能用到索引的快速搜索。(可以用到ICP)
在索引上,避免使用NOT、!=、>、!、NOT EXISTS、NOT IN、NOT LIKE等
案例7、优化器选择不使用索引的情况
如果要求访问的数据量很小,则优化器还是会选择辅助索引,但是当访问的数据占整个表中数据的蛮大一部分时(一般是20%左右),优化器会选择通过聚集索引来查找数据。
查询出所有未支付的订单,一般这种订单是很少的,即使建了索引,也没法使用索引。
案例8、复杂查询
如果是统计某些数据,可能改用数仓进行解决;如果是业务上就有那么复杂的查询,可能就不建议继续走SQL了,而是采用其他的方式进行解决,比如使用ES等进行解决。
案例9、asc和desc混用
desc 和asc混用时会导致索引失效
案例10、大数据
对于推送业务的数据存储,可能数据量会很大,如果在方案的选择上,最终选择存储在MySQL上,并且做7天等有效期的保存。那么需要注意,频繁的清理数据,会照成数据碎片,需要联系DBA进行数据碎片处理。
F. 数据库牛人是如何进行SQL优化的
SQL 查询优化减少了查询所需的资源并提高了整体系统性能,在本文中,我们将讨论 SQL 查询优化、它是如何完成的、最佳实践及其重要性。
SQL 查询优化是编写高效的 SQL 查询,并在执行时间和数据库表示方面 提高查询性能 的迭代过程,查询优化是几个关系数据库管理系统 (RDBMS) 的一项重要功能。
查询是对来自数据库的数据或信息的问题或请求,需要编写一组数据库可以理解的预定义代码,结构化查询语言 (SQL) 和其他查询语言旨在检索或管理关系数据库中的数据。
数据库中的查询可以用许多不同的结构编写,并且可以通过不同的算法执行,写得不好的查询会消耗更多的系统资源,执行时间长,并可能导致服务损失,一个完美的查询可以减少执行时间并带来最佳的 SQL 性能。
SQL查询优化的主要目的是:
确保查询处于最佳路径和形式非常重要,SQL 查询过程需要最好的执行计划和计算资源,因为它们是 CPU 密集型操作,SQL 查询优化通过三个基本步骤完成:
解析确保查询在语法和语义上都是正确的,如果查询语法正确,则将其转换为表达式并传递到下一步。
优化在查询性能中扮演着重要的角色,并且可能很困难,任何考虑优化的查询执行计划都必须返回与之前相同的结果,但优化后的性能应该会有所提高。
SQL 查询优化包括以下基本任务:
最后,查询执行涉及将查询优化步骤生成的计划转化为操作,如果没有发生错误,此步骤将返回结果给用户。
一旦用户确定某个查询需要改进以优化 SQL 性能,他们就可以选择任何优化方法——优化 SQL 查询性能的方法有很多种,下面介绍了一些最佳实践。
提高查询性能的一种简单方法是将 SELECT * 替换为实际的列名,当开发人员在表中使用 SELECT * 语句时,它会读取每一列的可用数据。
使用 SELECT 字段名 FROM 而不是 SELECT * FROM 时,可以缩小查询期间从表中提取的数据的范围,这有助于提高查询速度。
循环中的 SQL 查询运行不止一次,这会显着降低运行速度,这些查询会不必要地消耗内存、CPU 能力和带宽,这会影响性能,尤其是当 SQL 服务器不在本地计算机上时,删除循环内的查询可提高整体查询性能。
使用SQL 服务器索引可以减少运行时间并更快地检索数据,可以使用聚集和非聚集 SQL 索引来优化 SQL 查询,非聚集索引单独存储,需要更多的磁盘空间,因此,了解何时使用索引很重要。
该OLAP功能“扩展了SQL解析函数的语法。” SQL 中的 OLAP 功能更快且易于使用,熟悉这些语法的 SQL 开发人员和 DBA 可以很容易地适应和使用它们。
OLAP 函数可以创建所有标准计算度量,例如排名、移动聚合、份额、期初至今、前期和未来期、平行期等。
查询优化器使用统计信息来确定如何最好地连接表、何时应该使用索引以及如何访问这些索引等,无论是手动还是自动,SQL 服务器统计信息都应该保持最新。
过时的 SQL Server 统计信息会影响表、索引或列统计信息,并导致查询计划性能不佳。
SQL 查询优化可以轻松提高系统性能,从而节省成本,优化 SQL 查询可以提高运营效率并加快性能,从而提高系统上线进度。
SQL 查询优化很重要,原因有很多,包括:
组织可以通过更快的响应时间获得可靠的数据访问和高水平的性能,优化 SQL 查询不仅可以提高整体系统性能,还可以提高组织的声誉,最终,SQL 查询优化的最佳实践帮助用户获得准确、快速的数据库结果。
G. 如何进行SQL性能优化
这里分享下mysql优化的几种方法。
1、首先在打开的软件中,需要分别为每一个表创建 InnoDB FILE的文件。
H. SQL执行与优化
SQL优化
执行计划,表关联查询顺序,优化策略与思路
下面再向前走一些,容我根据自己的认识说一下查询执行的流程是怎样的:
1.连接
1.1客户端发起一条Query请求,监听客户端的‘连接管理模块’接收请求
1.2将请求转发到‘连接进/线程模块’
1.3调用‘用户模块’来进行授权检查
1.4通过检查后,‘连接进/线程模块’从‘线程连接池’中取出空闲的被缓存的连接线程和客户端请求对接,如果失败则创建一个新的连接请求
2.处理
2.1先查询缓存,检查Query语句是否完全匹配,接着再检查是否具有权限,都成功则直接取数据返回
2.2上一步有失败则转交给‘命令解析器’,经过词法分析,语法分析后生成解析树
2.3接下来是预处理阶段,处理解析器无法解决的语义,检查权限等,生成新的解析树
2.4再转交给对应的模块处理
2.5如果是SELECT查询还会经由‘查询优化器’做大量的优化,生成执行计划
2.6模块收到请求后,通过‘访问控制模块’检查所连接的用户是否有访问目标表和目标字段的权限
2.7有则调用‘表管理模块’,先是查看table cache中是否存在,有则直接对应的表和获取锁,否则重新打开表文件
2.8根据表的meta数据,获取表的存储引擎类型等信息,通过接口调用对应的存储引擎处理
2.9上述过程中产生数据变化的时候,若打开日志功能,则会记录到相应二进制日志文件中
3.结果
3.1Query请求完成后,将结果集返回给‘连接进/线程模块’
3.2返回的也可以是相应的状态标识,如成功或失败等
3.3‘连接进/线程模块’进行后续的清理工作,并继续等待请求或断开与客户端的连接
接下来再走一步,让我们看看一条SQL语句的前世今生。
首先看一下示例语句
示例语句
执行顺序
SQL解析
1. FROM
当涉及多个表的时候,左边表的输出会作为右边表的输入,之后会生成一个虚拟表VT1。
(1-J1)笛卡尔积
计算两个相关联表的笛卡尔积(CROSS JOIN) ,生成虚拟表VT1-J1。
两次全表扫描
哈希索引,查找复杂度都是 O(1) 。
2. WHERE
对VT1过程中生成的临时表进行过滤,满足WHERE子句的列被插入到VT2表中。
注意:
此时因为分组,不能使用聚合运算;也不能使用SELECT中创建的别名;
与ON的区别:
如果有外部列,ON针对过滤的是关联表,主表(保留表)会返回所有的列;
如果没有添加外部列,两者的效果是一样的;
应用:
对主表的过滤应该放在WHERE;
对于关联表,先条件查询后连接则用ON,先连接后条件查询则用WHERE;
hash join 哈希连接 驱动表和被驱动表都只会访问0次或1次
应用场景:一个大表一个小表/表上没有索引/返回结果集比较大
3. GROUP BY
这个子句会把VT2中生成的表按照GROUP BY中的列进行分组。生成VT3表。
注意:
其后处理过程的语句,如SELECT,HAVING,所用到的列必须包含在GROUP BY中,对于没有出现的,得用聚合函数;
原因:
GROUP BY改变了对表的引用,将其转换为新的引用方式,能够对其进行下一级逻辑操作的列会减少;
原作者的理解是:
根据分组字段,将具有相同分组字段的记录归并成一条记录,因为每一个分组只能返回一条记录,除非是被过滤掉了,而不在分组字段里面的字段可能会有多个值,多个值是无法放进一条记录的,所以必须通过聚合函数将这些具有多值的列转换成单值;
GROUP BY 重新聚合查询
4. HAVING
这个子句对VT3表中的不同的组进行过滤,只作用于分组后的数据,满足HAVING条件的子句被加入到VT4表中。
7.LIMIT
LIMIT子句从上一步得到的VT6虚拟表中选出从指定位置开始的指定行数据。
注意:
offset和rows的正负带来的影响;
当偏移量很大时效率是很低的,可以这么做:
采用子查询的方式优化,在子查询里先从索引获取到最大id,然后倒序排,再取N行结果集
采用INNER JOIN优化,JOIN子句里也优先从索引获取ID列表,然后直接关联查询获得最终结果
当前未用到索引,
三次full scan , table1 AS a / table2 AS b / GROUP BY
尽量少做重复的工作
控制同一语句的多次执/减少多次的数据转换/
杜绝不必要的子查询和连接表,子查询在执行计划一般解释成外连接,多余的连接表带来额外的开销
关于临时表和表变量的选择
临时表产生使用SELECT INTO和CREATE TABLE + INSERT INTO的选择,一般情况下,SELECT INTO会比CREATE TABLE + INSERT INTO的方法快很多,但是SELECT INTO会锁定TEMPDB的系统表SYSOBJECTS、SYSINDEXES、SYSCOLUMNS,在多用户并发环境下,容易阻塞其他进程,所以建议,在并发系统中,尽量使用CREATE TABLE + INSERT INTO,而大数据量的单个语句使用中,使用SELECT INTO。
子查询的用法
相关子查询可以用IN、NOT IN、EXISTS、NOT EXISTS引入
NOT IN、NOT EXISTS的相关子查询可以改用LEFT JOIN代替写法
如果保证子查询没有重复 ,IN、EXISTS的相关子查询可以用INNER JOIN 代替
IN``的相关子查询用EXISTS代替
不要用 COUNT (*)的子查询判断是否存在记录,最好用 LEFT` `JOIN 或者EXISTS,比如有人写这样的语句:
建立索引后,并不是每个查询都会使用索引,在使用索引的情况下,索引的使用效率也会有很大的差别。只要我们在查询语句中没有强制指定索引,
不要对索引字段进行运算,而要想办法做变换
不要对索引字段进行格式转换
不要对索引字段使用函数
不要对索引字段进行多字段连接
join关联查询的计算是很复杂的,特别是数据量比较大的情况下,实际情况还是拆解较快的
Join拆解的核心就是利用In关键字
要么用空间换时间,要么用时间换空间
多表连接的连接条件对索引的选择有着重要的意义,所以我们在写连接条件条件的时候需要特别注意。
A、多表连接的时候,连接条件必须写全,宁可重复,不要缺漏。
B、连接条件尽量使用聚集索引
C、注意ON、WHERE和HAVING部分条件的区别
ON是最先执行, WHERE次之,HAVING最后,因为ON是先把不符合条件的记录过滤后才进行统计,它就可以减少中间运算要处理的数据,按理说应该速度是最快的,WHERE也应该比 HAVING快点的,因为它过滤数据后才进行SUM,在两个表联接时才用ON的,所以在一个表的时候,就剩下WHERE跟HAVING比较了
考虑联接优先顺序:
(1)INNER JOIN
(2)LEFT JOIN (注:RIGHT JOIN 用 LEFT JOIN 替代)
(3)CROSS JOIN
索引并不适用于所有情况:a.少量数据;b.频繁进行改动的字段,不适合做索引;c.很少使用的字段,不需要加索引
索引会提高数据查询效率,但是会降低“增、删、改”的效率。当不使用索引的时候,我们进行数据的增删改,只需要操作源表即可,但是当我们添加索引后,不仅需要修改源表,也需要再次修改索引,很麻烦。
先执行顺序, 是否走索引, 有无类型转换
18000 字的SQL优化大全
步步深入:MySQL架构总览->查询执行流程->SQL解析顺序
MySQL索引总结(4)——btree与hash区别
I. SQL优化(二)
SQL优化一: sql优化(一)
上片文章已经详细介绍了explain各个字段的含义,以及什么情况应该建立索引,什么情况不需要建立索引以及sql语句性能的判断依据,接下来我介绍下如何合理的建立索引。
sql语句:select id,author_id from article where category_id = 1 and comments>1 order by views desc limit 1;
分析:首先我们根据where后面的条件建立符合索引,然后根据order by后面的字段建立索引,因此建立索引idx_article_ccv,即以(category_id,comments,views)数据列建立复合索引,但由于comments是一个范围,按照BTree索引的原理,先排序category_id,如果遇到相同的category_id则再排序comments,如果遇到相同的comments则再排序views,又因为comments字段在复合索引里处于中间位置,而comments>1是一个条件(是一个范围值),在复合索引的一个范围值的数据列后面的索引全部失效,mysql无法利用索引再对后面的views部分进行检索,也就是说views无法按照索引排序,所以explain下此sql语句,type为range,extra使用的是Using filesort,这是比较糟糕的。所以我们放弃comments这个范围字段,建立索引idx_article_cv,即以(category_id,views)数据列建立复合索引,explain 此sql,type变成了ref,extra的using filesort也变成了using index,这就变得好多了。
索引:idx_article_cv,即以(category_id,views)数据列建立复合索引
前段时间做了一个销售精细化项目,是公司crm项目的一个大模块,大致就是为销售人员制定指标,实现销售目标从区域到团到业务员到客户,实时跟踪业务员所负责客户的下单量的情况。这就存在许多关联关系,区域-团,团-业务员,业务员-客户,这使得sql常常需要关联多张表。
sql语句:SELECT
tu.fuserid,
tu.faccount,
tu.fphone,
tu.fcertificationtype,
tu.fcertificatename,
tu.fkeyarea,
tu.fkeyareatext,
DATE_FORMAT(tcr.fupdatetime,'%Y-%m-%d %H:%i:%s') as fupdatetime,
tag.forggroupid,
tag.forggroupname,
tug.forguserid,
tug.fusername,
tug.fuserphone,
tag.fcitycode
FROM t_finedt_user AS tu
LEFT JOIN t_finedt_customer_relation AS tcr
ON tu.fuserid = tcr.fuserid
LEFT JOIN t_finedt_usergroup AS tug
ON tcr.forguserid = tug.forguserid
and tcr.forggroupid = tug.forggroupid
LEFT JOIN t_finedt_areagroup AS tag
ON tug.forggroupid = tag.forggroupid
where tu.fkeyarea=? and tu.fuserid=? and tug.forggroupid = ?
分析:上面的sql是左连接,左边的表一定是全表查询,所以要建立右边表对应关联字段的索引,在表t_finedt_user上建立tu_fuserid_fkeyarea索引,即以(fuserid,fkeyarea)字段建立索引,在表t_finedt_customer_relation 上建立tcr_forguserid_forggroupid索引,即以(forguserid,forggroupid)字段建立索引,在表t_finedt_usergroup 上建立tug_forguserid_forggroupid索引,即以(forguserid,forggroupid)字段建立索引,在表t_finedt_areagroup上建立tag_forggroupid索引,即以(forggroupid)字段建立索引。建立索引后,sql查询速度明显快了很多
索引:tcr_forguserid_forggroupid,tu_fuserid_fkeyarea,tug_forguserid_forggroupid,tag_forggroupid
1、尽可能减少join语句中的NestedLoop的循环次数,永远用小结果集驱动大结果集
2、优先优化NestedLoop的内层循环
3、保证join语句总被驱动表上的join字段已经被索引
4、当无法保证被驱动表join条件字段被索引,且内存资源充足的前提下,不要太吝啬joinBuffer的设置
1、全值匹配我最爱
2、最佳左前缀原则——如果索引了多列,要遵守最左前缀原则,指的是查询从索引的最左前列开始并且不跳过索引中的列
3、并在索引列上做任何操作(计算、函数、自动or手动类型转换),这些会导致索引失效而转向全表扫描
4、存储引擎不能使用索引中范围条件右边的列,范围之后的索引全失效
5、尽量使用覆盖索引(之访问索引的查询(索引列和查询的列一致)),减少select *
6、mysql在使用不等于(!=、>、<)的时候无法使用索引会导致全表扫描。
7、is null、is not null也无法使用索引。
8、like以通配符开头("%abc.."),mysql索引失效也会变成全表扫描的操作。
9、字符串不加单引号也会引起索引失效
10、少用or,用它来连接时会索引失效。
1、对于单值索引,尽量选择针对当前query过滤性更好的索引
2、在选择组合索引的时候,当前query中过滤性最好的字段在索引字段顺序中,位置越靠前越好
3、在选择组合索引的时候,尽量选择尽可能包含当前query中的where字句中更多字段的索引
4、尽可能通过分析统计信息和调整query的写法来达到选择合适索引的目的。
全值匹配我最爱,最左前缀要遵守
带头大哥不能死,中间兄弟不能断
索引列上少计算,范围之后全失效
like百分写最右,覆盖索引不写里
不等空值还有or,索引失效要少用
var引号不可丢,sql高级也不难