数据库like前匹配快还是in

数据库前匹配快in。

like最差，特别是以%（有的数据库是）开头的匹配，是无法进行索引的，只有顺序扫描。

首先是=，表示值必须是一个特定的值。然后是in，表示值是几个特定的值中的一个。最后是like，通过匹配来查找值。其实还有一个is，只为null使用。

SQL对like *** 作中的特殊字符处理方法：

SQL Server查询过程中，单引号 ' 是特殊字符，所以在查询的时候要转换成双单引号 '' 。

在like *** 作还有以下特殊字符：下划线_，百分号%，方括号[]，尖号^。 其用途如下：下划线：用于代替一个任意字符（相当于正则表达式中的 ） 百分号：用于代替任意数目的任意字符（相当于正则表达式中的 ）。

方括号：用于转义（事实上只有左方括号用于转义，右方括号使用最近优先原则匹配最近的左方括号）。

尖号：用于排除一些字符进行匹配（这个与正则表达式中的一样）。

索引的创建很简单，可以网上查下相关信息，在这里只是说下索引需要注意的地方，索引分为很多不同的类型，一般咱们说的是B_Tree索引，这里就只说B_Tree，如果是哈希索引，可以网上找相关资料。

B_Tree适用于：

1全值匹配

全值匹配是指和索引中的所有列进行匹配。

2匹配最左前缀

匹配左左前缀即只使用索引的第一列

3匹配列前缀

匹配某一列开头部分（指的第一列）。

4匹配范围值

5精确匹配某一列并范围匹配另一列

6只访问索引的查询

只需访问索引，无需访问数据行。

B_Tree限制

1如果不是按照索引的最左列开始查找，则无法使用索引。

2不能跳过索引中的列。

3如果查询中有某个列的范围查询，则其右边左右列无法使用索引优化查找。

索引使用时，有统计信息，数据库选择最优索引，可以使用hint提示你想要使用的索引，多个字段组成的联合索引，符合最左匹配原则 index(a,b,c) 符合 where a=1 and b=1 或者 where a=1 或者 where a=1 and b=1 and c=1 都可以用到索引。where 条件包含的字段和索引排序一样。

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

tufuserid,

tufaccount,

tufphone,

tufcertificationtype,

tufcertificatename,

tufkeyarea,

tufkeyareatext,

DATE_FORMAT(tcrfupdatetime,'%Y-%m-%d %H:%i:%s') as fupdatetime,

tagforggroupid,

tagforggroupname,

tugforguserid,

tugfusername,

tugfuserphone,

tagfcitycode

FROM t_finedt_user AS tu

LEFT JOIN t_finedt_customer_relation AS tcr

ON tufuserid = tcrfuserid

LEFT JOIN t_finedt_usergroup AS tug

ON tcrforguserid = tugforguserid

and tcrforggroupid = tugforggroupid

LEFT JOIN t_finedt_areagroup AS tag

ON tugforggroupid = tagforggroupid

where tufkeyarea= and tufuserid= and tugforggroupid =

分析：上面的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高级也不难

以上就是关于数据库like前匹配快还是in全部的内容，包括:数据库like前匹配快还是in、mysql索引是如何实现的、oracle数据库多列唯一约束产生的多列索引，只用了中间字段索引怎么也生效，多列唯一索引的触发条件是什么等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！