-
本版专家分：0结帖率 100% -
语句如下：
SELECT substr(orgCode,1,instr(orgCode, '.',1,3)) orgCode,SUM(s.MONTH_ADD)
from SPECIL_TASK_REPORT s
WHERE ((s.year = 2018 and s.month >= 7 or (s.year > 2018))
and ((s.year = 2018 and s.month <= 12) or (s.year < 2018)))
GROUP BY substr(orgCode,1,instr(orgCode, '.',1,3))
执行计划：
索引：
数据量大概1千万，如何能满足走索引查询
-
本版专家分：704 -
确定括号没有问题？你这语句就不是你想要的……
-
本版专家分：8835
-
- 红花 2019年6月 Oracle大版内专家分月排行榜第一
-
-
黄花
2019年5月 Oracle大版内专家分月排行榜第二
2018年1月 Oracle大版内专家分月排行榜第二
2017年10月 Oracle大版内专家分月排行榜第二
-
-
蓝花
2017年12月 Oracle大版内专家分月排行榜第三
2017年11月 Oracle大版内专家分月排行榜第三
2017年9月 Oracle大版内专家分月排行榜第三
-
-
这条件拼出来的吧，绕来绕去就是2018年7月到12月的数据，半年的数据应该是不会少的，CBO现在估算的300多万，数据太多了，全表扫描极有可能是正确的路径。
-
本版专家分：8835
-
- 红花 2019年6月 Oracle大版内专家分月排行榜第一
-
-
黄花
2019年5月 Oracle大版内专家分月排行榜第二
2018年1月 Oracle大版内专家分月排行榜第二
2017年10月 Oracle大版内专家分月排行榜第二
-
-
蓝花
2017年12月 Oracle大版内专家分月排行榜第三
2017年11月 Oracle大版内专家分月排行榜第三
2017年9月 Oracle大版内专家分月排行榜第三
-
-
看上去这张表还是个一级list分区，用的year字段采用的年度分区？扫描的应该是2018年的这个分区数据，按照你取了半年的数据来看，这样的计划可以了，走索引反而不行。
-
本版专家分：0
-
你好，确实是分区表，半年的数据300多万，是不是数据量大了，优化器选择了表扫描，而且刚才查了下，年月索引重复性特别高
现在查询差不多平均10秒，在不做结构变化的情况下，有没有优化的余地了呢？
-
本版专家分：8835
-
- 红花 2019年6月 Oracle大版内专家分月排行榜第一
-
-
黄花
2019年5月 Oracle大版内专家分月排行榜第二
2018年1月 Oracle大版内专家分月排行榜第二
2017年10月 Oracle大版内专家分月排行榜第二
-
-
蓝花
2017年12月 Oracle大版内专家分月排行榜第三
2017年11月 Oracle大版内专家分月排行榜第三
2017年9月 Oracle大版内专家分月排行榜第三
-
-
返回数据量太大，或者占整表数据的比例太高，用索引是不合适的，分区就是用来对付这种不可避免的全表扫描操作的，可以扫描一个或者几个分区，来避免扫描整张表所有的数据。
300多万的数据，应该是没法继续常规的优化了，如果要优化，而且这张表的字段很多的话，可以考虑在这个sql里涉及到的所有字段上（包括select列表、where条件以及group子句中引用到的字段）创建组合索引，相当于将该表垂直分割，有点类似使用列存数据库了，这样减少整体扫描的数据，节省IO。
-
本版专家分：8835
-
- 红花 2019年6月 Oracle大版内专家分月排行榜第一
-
-
黄花
2019年5月 Oracle大版内专家分月排行榜第二
2018年1月 Oracle大版内专家分月排行榜第二
2017年10月 Oracle大版内专家分月排行榜第二
-
-
蓝花
2017年12月 Oracle大版内专家分月排行榜第三
2017年11月 Oracle大版内专家分月排行榜第三
2017年9月 Oracle大版内专家分月排行榜第三
-
-
忘记说了，在大表上多几个索引字段的代价会比较高的，会影响DML语句的性能，尤其是批量处理数据的时候，你会发现效率会与没有索引的时候差的不是一星半点。
-
本版专家分：8835
-
- 红花 2019年6月 Oracle大版内专家分月排行榜第一
-
-
黄花
2019年5月 Oracle大版内专家分月排行榜第二
2018年1月 Oracle大版内专家分月排行榜第二
2017年10月 Oracle大版内专家分月排行榜第二
-
-
蓝花
2017年12月 Oracle大版内专家分月排行榜第三
2017年11月 Oracle大版内专家分月排行榜第三
2017年9月 Oracle大版内专家分月排行榜第三
-
-
三连下
如果以SQL的执行时间为标准来判断SQL性能的好坏，最好多执行几次，取稳定时间为准，因为有buffer cache缓存的影响。
-
本版专家分：0
-
好的，明白了，谢谢，我考虑拆表弄了
-
本版专家分：2
-
你可以做函数索引啊
-
本版专家分：8835
-
- 红花 2019年6月 Oracle大版内专家分月排行榜第一
-
-
黄花
2019年5月 Oracle大版内专家分月排行榜第二
2018年1月 Oracle大版内专家分月排行榜第二
2017年10月 Oracle大版内专家分月排行榜第二
-
-
蓝花
2017年12月 Oracle大版内专家分月排行榜第三
2017年11月 Oracle大版内专家分月排行榜第三
2017年9月 Oracle大版内专家分月排行榜第三
-
-
可以先试下建组合索引，拆表的代价毕竟更高
-
本版专家分：489
-
-
红花
2019年4月 其他数据库开发大版内专家分月排行榜第一
2019年3月 其他数据库开发大版内专家分月排行榜第一
-
-
先不说技术，您的逻辑就有很大的优化空间，您试试这个。
SELECT substr(orgCode,1,instr(orgCode, '.',1,3)) orgCode,SUM(s.MONTH_ADD)
from SPECIL_TASK_REPORT s
WHERE s.year = 2018 and s.month between 7 and 12
GROUP BY substr(orgCode,1,instr(orgCode, '.',1,3))
-
本版专家分：0
-
试过了组合索引，优化器还是不用
-
本版专家分：0
-
早试过了，不走索引的都是 full table access
-
本版专家分：8835
-
- 红花 2019年6月 Oracle大版内专家分月排行榜第一
-
-
黄花
2019年5月 Oracle大版内专家分月排行榜第二
2018年1月 Oracle大版内专家分月排行榜第二
2017年10月 Oracle大版内专家分月排行榜第二
-
-
蓝花
2017年12月 Oracle大版内专家分月排行榜第三
2017年11月 Oracle大版内专家分月排行榜第三
2017年9月 Oracle大版内专家分月排行榜第三
-
-
再说一遍吧，不走现在的索引范围扫描是对的。。。
如果说后来的覆盖组合索引没走，你可以放出索引的DDL脚本看下，如果索引建好了，应该是走index fast full scan，而不是你原先期待的index range scan～
-
本版专家分：8835
-
- 红花 2019年6月 Oracle大版内专家分月排行榜第一
-
-
黄花
2019年5月 Oracle大版内专家分月排行榜第二
2018年1月 Oracle大版内专家分月排行榜第二
2017年10月 Oracle大版内专家分月排行榜第二
-
-
蓝花
2017年12月 Oracle大版内专家分月排行榜第三
2017年11月 Oracle大版内专家分月排行榜第三
2017年9月 Oracle大版内专家分月排行榜第三
-
-
对了，想到一种可能，这个SQL里引用到的字段上，是不是没有not null约束或者主键约束，如果是的话，那么可以尝试在原来的索引字段组合中加个常量0，比如这样的索引：(a,b,c,0)，其中a、b、c为SQL引用的字段组合，或者，你可以在SQL中加上一个not nul的条件，无论是引用到的哪个字段都可以，当然是在不影响业务含义的基础上。
-
本版专家分：0
-
下载来看看，好东西
-
本版专家分：0
-
下一手看看....
-
本版专家分：0
-
-
本版专家分：0
-
or 查询对于使用索引是有影响的，你也可以使用指定使用索引的语法。
- SQL索引字段使用函数操作导致不走索引
- 今天在做SQL Tuning的时候遇到一个典型的example，立个Flag，梳理知识点，在这里也做个分享，就是我们在写SQL的时候如果对<em>索引</em><em>字段</em>使用函数炒作，则导致该SQL不走<em>索引</em>扫描查询，导致SQL性能下降。nSQL如下：nSELECT NVL(A.USER_NAME_C, NVL(A.USER_NAME_E, A.USER_CODE)) USER_NAME, n A.TEL_NO, n A....
- IN 查询的时候索引不起作用？
- 其实很简单，<em>索引</em>是否起叙用，主要取决于<em>字段</em>类型：rn1. 如果<em>字段</em>类型为字符串，需要给in查询中的数值与字符串值都需要添加引号，<em>索引</em>才能起作用。rn2. 如果<em>字段</em>类型为int，则in查询中的值不需要添加引号，<em>索引</em>也会起叙用。rnIN的<em>字段</em>，在联合<em>索引</em>中，按以上方法，也会起作用。
- oracel 字段不走索引
- 用oracle做全表查询时发现一个<em>问题</em>，如果数据库某个varchar2类型的<em>字段</em>建了<em>索引</em>，但是查询的时候扔进入的值是long或integer类型的数据，oracle会不走<em>索引</em>，oracle会对传入的参数做to_char()处理，所以不会走<em>索引</em>。 n走<em>索引</em>如果参数不是字符串类型，而是数字类型，则不走<em>索引</em>。走<em>索引</em> nselect t.username,t.userpassword,t.sex,t.add
- oracle left join走不到索引问题分析
- 写了个left join语句，如下：nnselect A.c,B.dnnfrom Annleft join Bnnon A.a = B.annand A.b = B.bnn对A表的a, b<em>字段</em>和B表的a, b<em>字段</em>都建了联合<em>索引</em>, 发现on后的条件怎么也走不到<em>索引</em>nn查到有个说法是只有where后的语句可以走到<em>索引</em>，试着改为(+)nnselect A.c,B.dnnfrom A, Bnnwhere ...
- MySQL使用索引优化DISTINCT操作
- MySQL通常使用GROUPBY(本质上是排序动作)完成DISTINCT操作,如果DISTINCT操作和ORDERBY操作组合使用,通常会用到临时表.这样会影响性能. 在一些情况下,MySQL可以使用<em>索引</em><em>优化</em>DISTINCT操作,但需要活学活用.本文涉及一个不能利用<em>索引</em>完成DISTINCT操作的实例.rnrn实例1 使用<em>索引</em><em>优化</em>DISTINCT操作rncreate table m11 (a int
- SQL Server 索引优化—— 查询条件中等于、大于或小于条件在索引中的顺序对性能的影响
- SQL Server <em>索引</em><em>优化</em>nn—— 查询条件中等于、大于或小于条件在<em>索引</em>中的顺序对性能的影响nn一、准备测试表和数据nnnuse testngoncreate table tradeDetail(n id int identity(1,1)n ,productId intn ,tradedate datetimen ,[description] ...
- select 建立了索引但是不走索引
- create index indexName on A(abc);此时select abc from A 不走<em>索引</em>。。。。可用如下方法让搜索走<em>索引</em>select distinct(abc) from A a where exists (select 1 from A b where a.abc=b.abc)红色部分必须一致。...
- 索引优化MAX()
- 看本文之前，建议先阅读：http://blog.csdn.net/qq_33290787/article/details/51934999普通的 MAX() SQL执行计划：从执行计划中可以看到：本次SQL查询检索了payment表（全表扫描，FTS），一共检索了16086行数据。意味着从磁盘中读取了16086行数据至my<em>sql</em>服务端内存中进行最大值判断（有数据IO）。为payment_date建立
- MySQL：UNIX_TIMESTAMP函数不走索引问题
- 关于时间戳的类型转换n取当时的时间戳函数nmy<em>sql</em>> SELECT UNIX_TIMESTAMP(TIMESTAMP(DATE(SYSDATE()))),UNIX_TIMESTAMP(NOW());n+--------------------------------------------+-----------------------+n| UNIX_TIMESTAMP(TIMESTAMP(
- select *与select 无索引列以及select 有索引列的比较
- select *与select 无<em>索引</em>列以及select 有<em>索引</em>列的比较
- 解决mysql中in子查询导致不走索引
- 原<em>sql</em>为：nnnSELECT n SUM(money)nFROMn walletnWHEREn user_id IN (SELECT DISTINCTn user_idn FROMn user_rechargen WHEREn group_id = '6789' AND is_del=...
- or连接是否会使用索引
- or连接条件<em>字段</em>，全部设置<em>索引</em>的时候，才会使用<em>索引</em>，否则将不会使用<em>索引</em>。nnnn验证如下：nn数据表结构如下nnnncreate TABLE bookn(nbookid INT NOT NULL primary key auto_increment,nbookname VARCHAR(255) NOT NULL ,nauthors VARCHAR(255) NOT NULL,ninfo VARCH...
- 优化案例4----错误的大表走HASH+并行----->正确的走Nested loop
- 谈到大表与大表之间的连接方式，总会下意识的选择走HASH JOIN+并行效率才高，其实具体情况必须具体<em>问题</em>，在有的时候，大表走嵌套循环的效率要优于走HASH JOIN，下面就用我之前<em>优化</em>过的一个案例来说明。n 一个哥们找我<em>优化</em>一个SQL 跑的很慢，103万个逻辑读，103万个物理读，要跑19秒才能跑完。n 下面是它的SQL 以及执行计划：n SELECT "A1"
- Mybatis的Date类型不走索引的问题
- rn该<em>问题</em>出现在ORACLE 数据库，其他数据库没有试过。rn如果JAVA中的属性为DATE,而数据库中是DATE类型的话。mybatis会默认将JAVA中DATE属性映射到数据库的rnTimestamp类型。这时就会有这样的查询rnｗｈｅｒｅ create_time &gt;= v_timern左边为DATE右边为Timestamp.类型不一致，ORACLE会隐式将小的转成大的。rn也就是变成这...
- 什么样的sql不走索引
- 什么样的<em>sql</em>不走<em>索引</em>rnrn要尽量避免这些不走<em>索引</em>的<em>sql</em>rnSELECT `sname` FROM `stu` WHERE `age`+10=30;-- 不会使用<em>索引</em>,因为所有<em>索引</em>列参与了计算 nnSELECT `sname` FROM `stu` WHERE LEFT(`date`,4) 1990; -- 不会使用<em>索引</em>,因为使用了函数运算,原理与上面相同 nnSELECT * FROM `h
- 单个字段 OR 与 多字段OR
- 单<em>字段</em> 可以用 in 代替 ornne.g status in (2,3) ====== status =2 or status = 3nn多<em>字段</em>只能 or 拼接nn固定的条件最好放在前面可以提高效率
- postgresql 优化之--不会使用索引
- --原始表结构如下：npostgres=# \d+ postgres_s1_logn Table "public.postgres_s1_log"n Column | Type | Modifiers | Storage | Stats
- MySQL查询优化之二-范围优化(Range Optimization)
- MySQL查询<em>优化</em>之二-范围<em>优化</em>(Range Optimization)rnrnrnrn如需转载请标明出处：http://blog.csdn.net/itas109 rnQQ技术交流群：12951803rnrn环境： rnMySQL版本：5.5.15 rn操作系统：windowsrnrn本文讨论范围的<em>优化</em>。 rn范围访问方法使用一个单独的<em>索引</em>来取回一个表记录的子集, 包含在一部分或者多个部分, <em>索引</em>值区间。它可用于
- SQL不走索引的情况
- 1、有应用于谓词的函数rn2、数据类型不匹配rn3、统计信息陈旧rn4、列可能包含空值rn5、使用<em>索引</em>实际上比不使用<em>索引</em>更慢
- ORACLE提高查询效率强制走索引
- select /*+index( b HR_EXAM_PAPER_PER_HIS_IDX)*/ ---括号内写的是表的<em>索引</em>名称 b.PKID, (CASE WHEN b.ANSWER = b.RIGHT_ANSWERS THEN 'Y' ELSE 'N' END) IF_RIGHT ...
- mysq order by 不走索引问题
- <em>问题</em>描述n今天遇到一个<em>问题</em>，在一个报表导出的功能中，需要导出用户的某些记录的所有数据，有些用户有多达10万的记录，导出过程非常慢，需要10多秒。经过排查，发现是查询数据库的时候的<em>问题</em>，查询数据居然用了7秒左右。起初看到<em>sql</em>没发现什么问，<em>sql</em>写得中规中矩，只查询需要的列，使用<em>索引</em>，遵循<em>索引</em>规则等等，但是他就是要那么长时间。n<em>问题</em>分析n表面上看不出<em>问题</em>，那只能用explain大法来分析分析了，n原...
- MongoDB索引调优（2）——[十]
- rn转载请出自出处：http://eksliang.iteye.com/blog/2178555rn一、概述rn 上一篇文档中也说明了，MongoDB的<em>索引</em>几乎与关系型数据库的<em>索引</em>一模一样，<em>优化</em>关系型数据库的技巧通用适合MongoDB，所有这里只讲MongoDB需要注意的地方rn二、<em>索引</em>内嵌文档rn 可以在嵌套文档的键上建立<em>索引</em>，方式与正常的键一样。如果有这样一个集合，如下所示：r...
- 【实际项目】根据时间范围查询优化
- 根据所传条件在SQL中添加时间范围：nnn<em>sql</em>.append("and (stationDateB) &gt;= (\'" + detailreportpojo.getStartdate() + "\') n and (stationDateE) &lt;= (\'" + detailreportpojo.getEnddate() + "\') ");nn需要<em>两个</em>时间<em>字段</em>都...
- mysql时间范围查询 索引无效
- https://ask.csdn.net/questions/719039nn对于range类型，选择性小于17%了，就会走全表扫描，而非rangennmy<em>sql</em>nnmy<em>sql</em>时间范围查询 <em>索引</em>无效 5Cnnnn死活不走带时间的<em>索引</em> 求大佬帮忙给个解决方案~nn编辑于：2018.12.29 16:59nn0nn分享nn|评论0|收藏0|浏览199nnnnZoeLulurnn声望： 0nn4个回答n...
- MySQL字符集不一致导致索引失效
- <em>两个</em>表join查询，却不走连接条件的<em>索引</em>。当<em>索引</em>无<em>问题</em>，<em>sql</em>也无<em>问题</em>时，就可以去看看这<em>两个</em>表的字符集是否一致，这是我耗费一个下午得出来的经验教训。
- mysql 联合索引＞ 和 order by 不走 索引 慎用
- 我有一个联合<em>索引</em>idx_css(createddate,storeId,site)rnEXPLAIN nSELECT * FROM statis_domain AS a WHERE a.`createddate` > '2015-04-23' AND a.`storeId` = 0rn现有以上<em>sql</em>语句，竟然用不到联合<em>索引</em>。rn解决办法：1、createddate>'time1' and cre
- ORACLE sql调优之记录一次trim函数引发的大表全表扫描
- 开发或测试为什么不在应用的前端对pid执行前后去空格的函数trim，反而非要放在数据库端执行，这样不但加重了数据库服务器的工作负担，还很容易导致这种因函数使用不当引起大表的全表扫描而降低<em>sql</em>的执行速度；虽然，对pid<em>字段</em>创建基于trim的函数<em>索引</em>能提升<em>sql</em>的执行效率，但是相比普通的<em>索引</em>基于trim的函数<em>索引</em>，一定会大大降低dml语句的执行效率；如果trim这种去空格的函数放在web前端进行，数据库则可免去这种不必要的性能损失。
- oracle sql强制走索引提高查询效率
- 一般建表的时候加了缩影，使用这张表的对应<em>字段</em>的时候，会走缩影，但是有时候会出现飘<em>索引</em>的现象；建议加上强制走<em>索引</em>的条件:rnselect /*INDEX(bmq OPERATOR_CARD_MATCHED_IDX1)*/n xx1,n xx2nfrom table_name bmqrn注意:只能使用别名，即bmq来强制走<em>索引</em>.
- mysql like为什么不走索引，如何改写
- 本文旨在用最通俗的语言讲述最枯燥的基本知识：nn这个话题比较有意思。n昨天中午吃完饭间突然有个同事蹦出了一句：“like有<em>索引</em>吗？”，我顺口就说没有，另一个同事反驳说有啊，还有些同事说看情况的有，这下有点懵逼了，都不知道那种说法是正确的，于是决定花了个半小时来研究验证这个<em>问题</em>，终于得到答案。nn怎么验证的呢？nnn坊间有传言：MySQL性能<em>优化</em>有个神器，叫做explain，它可以对select语句...
- 关于sqlserver in 走不走索引
- 先看图rnrnrn看懂了吗，当数据量较少时，没有走<em>索引</em>。当插入10万数据之后，走了<em>索引</em>。大多数说 in 不走<em>索引</em>，可能就在于测试的时候插入的数据量不多导致的吧~
- 数据库总结 函数、索引、SQL优化...
- 1.简述Oracle中的DML、DDL、DCL、TCL•DML(数据操作语言)：主要指的是数据库的查询和更新操作。如select、insert、update、delete、call等。•DDL(数据定义语言)：主要指的是数据对象(表、用户)的创建。如create、alter、drop、truncate、rename等。•DCL(数据控制语言)：主要指的是进行权限的管理和操作。如grant、revo...
- 性别字段建立索引问题
- 性别<em>字段</em>能不能建立<em>索引</em>nn之前面试被问到一个<em>问题</em>nn什么<em>字段</em>适合建<em>索引</em>，什么<em>字段</em>不适合建<em>索引</em>。nn性别<em>字段</em>可以建<em>索引</em>吗？nn我回答得不是很好。nn性别<em>字段</em>这种重复性很强的<em>字段</em>，不要建立<em>索引</em>。为什么不能呢？nn下面建立表测试下。如：我建了个tb_test表，往里面插入了七百多万数据，先给性别建立<em>索引</em>，查询开启 <em>sql</em>运行时间记录。nn创建名为tb_index_test 的<em>索引</em>nnnalter ta...
- 面积范围区间怎么写查询语句（两个字段参数的）
- 面积200-500平米【大于200平米且小于等于500平米】面积最大值 area_max面积最小值 area_min请问这应该怎么编写查询语句了
- pg数据库日期字段索引查询优化
- 有时候我们在使用<em>sql</em>查询的时候，会涉及到根据日期查询内容，通常做法都是通过日期<em>字段</em> &gt;= 来判断日期范围的，当数据量大了，你会发现查询速度就会很慢，这时候我们可以做些<em>优化</em>，给日期<em>字段</em>建立<em>索引</em>，更改查询语句，如下例子：nn select * from fcz_moment where dep_airport_code='CTU' and air_date ~'2018-02|2...
- MySQL中不等号索引问题
- 最近在使用MySQL中的一个小总结。nn在MySQL中，不等号&lt;&gt;在主键<em>字段</em>和唯一<em>索引</em><em>字段</em>中会走<em>索引</em>，在普通<em>索引</em>的<em>字段</em>上不会走<em>索引</em>。nn nn1.当不等号&lt;&gt;作用在普通<em>索引</em><em>字段</em>上nn nn表信息：nnnn使用explain查看普通<em>索引</em><em>字段</em>，没有走<em>索引</em>nnnn2.当不等号&lt;&gt;作用在主键<em>索引</em><em>字段</em>上nn nn使用explain查看主键<em>索引</em><em>字段</em>，走<em>索引</em>。nnnn nn3...
- mysql不走索引总结
- 在my<em>sql</em>查询语句中，总会发现明明已经建立了查询<em>字段</em><em>索引</em>，可是却没有用到，这是因为在my<em>sql</em>中有些查询语句是用不到<em>索引</em>的，总结如下，以供大家分享。1.like语句 n2.列类型为字符串类型，查询时没有用单引号引起来 n3.在where查询语句中使用表达式 n4.在where查询语句中对<em>字段</em>进行NULL值判断 n5.在where查询中使用了or关键字, myisam表能用到<em>索引</em>， innodb不行
- SQL 年月分开时查询一段时间
- CONVERT(datetime, concat(#{year},'-',#{month},'-1'), 120)nn这个可以转化为1992-2-1为时间<em>字段</em>
- mysql 索引 大于等于 走不走索引 最左前缀
- 你可以认为联合<em>索引</em>是闯关游戏的设计例如你这个联合<em>索引</em>是state/city/zipCode那么state就是第一关 city是第二关， zipCode就是第三关你必须匹配了第一关，才能匹配第二关，匹配了第一关和第二关，才能匹配第三关你不能直接到第二关的<em>索引</em>的格式就是第一层是state，第二层才是city上面举例介绍来源 https://zhidao.baidu.com/question/1863
- ORACLE 不走索引（失效）的原因以及解决办法
- 今天在做程序的时候发现原先写的<em>索引</em>竟然莫名奇妙地失效了。去找了一下大概原因如下，做了分析心得写上，希望能帮助大家rn首先了解失效<em>索引</em>的原因rn 1,rnrn 2,单独的>,rnrn 3,like "%_" 百分号在前.rnrn 4,表没分析.rnrn 5,单独引用复合<em>索引</em>里非第一位置的<em>索引</em>列.rnrn6,字符型<em>字段</em>为数字时在where条件里不添加引号.rnrnrn7,对<em>索引</em>列进行运算.需要建
- MySQL-5.7在多列索引 in条件查询的优化
- 山谷中偶遇，分享出来。某日（ri），zabbix my<em>sql</em>慢日志监控发现很多陌生的慢查询。 rn大概如下：SELECT * FROM `entry_device` WHERE (`entry_no`, `device_udid`) IN (('464580908742086656', 'ffffffffdeaea5fcffffffff96fddfcf')), ('464109860674342912
- MySQL对varchar型字段的索引，字段类型不同造成的隐式转换，导致索引失效
- MySQL<em>索引</em>使用：<em>字段</em>为varchar类型时，条件要使用”包起来，才能正常走<em>索引</em> n表user 里的id是BigInt类型，order表里关联到user表的id误建成userId varchar类型了，在ibatis上查询时，直接传入id Long类型，SQL查询非常慢，即使建立了userId<em>索引</em>，于是改成String 类型的userId去查询，SQL立马变的很快了。nnn http://ww...
- 【踩坑】MySQL时间索引失效
- 项目中查时间数据段数据时，发现查询时间很长，RDS查了一下执行计划：nnnn各列解析说明：nnnid：表示执行的顺序，id的值相同时，执行顺序是从上到下，id的值不同时，id的值越大，优先级越高，越先执行nnselect_type:nn1、SIMPLE表示不包含子查询和unionnn2、查询中若包含子查询，最外层查询则标记为：PRIMARYnn3、在select或者where列表中包含了子查询，则...
- Oracle 强制索引 增加搜索效率
- Oracle 强制<em>索引</em> 增加搜索效率通用格式执行计划检查n通用格式nselect 后边追加n/*+ index(表名（或别名 <em>索引</em>名)*/ nn例如nselect /*+ index(b IDX_KC24_AAC001)*/akb020,--定点医疗机构编码n akc190,--住院号（门诊号）n aae072,--单据号n aka135 bka135,--交易...
- Mysql中哪些Sql不走索引
- 要尽量避免这些不走<em>索引</em>的<em>sql</em>：rnSELECT `sname` FROM `stu` WHERE `age`+10=30;-- 不会使用<em>索引</em>，因为所有<em>索引</em>列参与了计算 nnSELECT `sname` FROM `stu` WHERE LEFT(`date`,4) 1990; -- 不会使用<em>索引</em>，因为使用了函数运算，原理与上面相同 nnSELECT * FROM `houdunwang` WHE
- Oracle优化——LIKE与索引（以%开头的LIKE会不走索引或走索引全扫描）
- 这样会走<em>索引</em>范围扫描，因为这个表达式有前导性。nSH@ prod> set autotrace onnSH@ prod> select max(cust_credit_limit) , count(*) from customers_ne where cust_last_name like 'Vaugh%' ;nnMAX(CUST_CREDIT_LIMIT) COUNT(*)n--------
- mysql索引列为空，也可以走索引
- 执行计划：nn查询结果：
- 数据库优化之(创建索引、分表、读写分离、缓存）
- 数据库<em>优化</em>之创建<em>索引</em>n<em>索引</em>（Index）是帮助DBMS高效获取数据的数据结构。n分类：普通<em>索引</em>/唯一<em>索引</em>/主键<em>索引</em>/全文<em>索引</em>。n普通<em>索引</em>: 允许重复的值出现；n唯一<em>索引</em>: 除了不能有重复的记录外，其它和普通<em>索引</em>一样(用户名、用户身份证、email、tel)；n主键<em>索引</em>：是随着设定主键而创建的，也就是把某个列设为主键的时候，数据库就会給改列创建<em>索引</em>。这就是主键<em>索引</em>，唯一且没有null值；n全文<em>索引</em>:...
- [InnoDB]性别字段为什么不适合加索引
- 表结构与数据nid为主键，id为5,15,25,35…时sex=1nsex=0,90000条数据;sex=1,10000条数据nnCREATE TABLE `people` (n `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,n `name` varchar(255) DEFAULT NULL,n `sex` tinyint(1) unsi...
- 关于SQL中关键字Like用到索引的情况
- 在Sybase数据库表中<em>字段</em>columnName上创建<em>索引</em>：rnset showplan on 查看执行计划性rnrncolumnName like 'partvalue%' %在后使用<em>索引</em>rncolumnName like '%partvalue' %在前不使用<em>索引</em>rncolumnName like '%partvalue%' 不使用<em>索引</em>rn'allvalue' like columnNam...
- sql优化----不同写法下group by 的影响
- 今天要对实现这样的一个统计效果的<em>sql</em>进行<em>优化</em>。nnn分析：可以看出此统计是要求针对经销商，车系<em>两个</em>维度对试驾次数和潜客数<em>两个</em>指标进行统计，试驾率是由这<em>两个</em>指标进行计算而得到。n1、维度：经销商，车系n2、指标：试驾次数，潜客数n原版<em>sql</em>如下:n分析<em>问题</em>：此<em>sql</em>给人的第一印象就是用了子查询效率低，事实它确实特别慢。而且对于不熟悉业务的人来说想看懂很痛苦。n 所以我选择了重
- mysql字段类型为char类型，建立索引但未使用原因
- 最近在做my<em>sql</em><em>索引</em>测试，新建了一个数据表，为<em>两个</em><em>字段</em><em>分别</em>建立普通<em>索引</em>，本来是为了测试其他的情况做准备，开始之前，<em>分别</em>对这<em>两个</em><em>字段</em>进行了一个简单的查询操作，explain一下不当紧，一下颠覆了我的认知，我明明只是使用了where <em>字段</em>名=<em>字段</em>值 操作，按理说应该是走<em>索引</em>的呀，为什么不走了？不甘心，我又测试几遍，type类型都是ALL，全表查询，为什么，难道where <em>字段</em>名=<em>字段</em>值本来就不
- SQL Server 索引优化——重复索引（部分重复）
- SQLServer<em>索引</em><em>优化</em>——重复<em>索引</em>（部分重复）nn前文给出了查询完全重复<em>索引</em>方法，但更多的情况下，是多个管理员，根据单个或部分查询，创建其各自需要的<em>索引</em>，而没有考虑整体情形，就会出现大量的部分重复<em>索引</em>，这对OLAP来说没有较大的影响，但对于OLTP系统，频繁的数据变更就会造成大量的性能消耗，同时也会增加存储的压力。所以对于这部分的<em>索引</em>的<em>优化</em>也显得非常有重要。我们可以这样理解部分重复<em>索引</em>，即...
- 索引失效系列——隐式类型转换
- n<em>索引</em>是我们进行<em>优化</em>的一种重要方式。实际工作中，一个简单的<em>索引</em>，可能就会大大提升提高关键业务作业效率，最终提升用户满意度。在CBO时代，DBA和开发人员经常为<em>索引</em>为什么不出现在执行计划中而困惑。rn rn<em>问题</em>提出rn rn下面是一个模拟的开发场景。rn rn//构建数据表rn rnSQL&gt; create table t as select * from dba_objects ;rn rnT...
- mysql 时间索引失效
- 项目中查询时间断的数据发现查询时间很长。怀疑没有走时间的<em>索引</em>，于是explain一下rnEXPLAIN select * from t_order where created_at>'2015-01-01 00:00:00' and created_atrnrnrnrn解析：rnid：rn表示执行的顺序，id的值相同时，执行顺序是从上到下，id的值不同时，id的值越大，优先级越高，越先执行rnse
- mysql left join 无法使用上索引
- my<em>sql</em> left join 的原则上有两点nnn左表为小表n右表的关联<em>字段</em>是<em>索引</em>nnn遇到的<em>问题</em>：右表（c）是大表，<em>分别</em> 有<em>两个</em>小表(a和b)nn当 a left join c 的时候可以使用上c的关联<em>字段</em><em>索引</em>，nn但是b left join c 的时候无法使用上<em>索引</em>，全文搜索了，nn<em>两个</em>小表的结构表面看起来一样，后面使用 show full columns from [tables]nn发现...
- 一则count(*) count(1) 为啥没有走索引的遭遇
- 一个超级简单的语句 select count（1） from lixora ； 开发反馈很慢，走了全表扫描，并且反馈说该表上有3个单列<em>索引</em>rn一般就2种原因： rn1.统计信息不对rn2.<em>索引</em>列为 nullable rnrnrn当时先让开发的兄弟使用 index hint 强制走了下<em>索引</em>，速度飞快，rn然后 再select count（lixora） from lixora ，发现也是走<em>索引</em>；rn
- MongoDB索引说明及慢查询优化
- 文章目录<em>索引</em>种类<em>索引</em>语法慢查询<em>优化</em>第一步：找出慢查询语句第二步：分析慢查询第三步：分析explain结果<em>索引</em><em>优化</em>实战<em>索引</em>建议n<em>索引</em>种类n<em>索引</em>通常能够极大的提高查询的效率,如果没有<em>索引</em>,MongoDB在读取数据时必须扫描集合中的每个文件并选取那些符合查询条件的记录，即会进行全集合扫描n<em>索引</em>主要用于排序和检索n单键<em>索引</em>（常用）n在某一个特定的属性上建立<em>索引</em>,例如:db.users.createInde...
- SQL优化案例-正确的使用索引（二）
- 下面<em>sql</em> 30秒执行出结果，查看<em>sql</em>谓词中有like，我们知道谓词中有这样的语句是不走<em>索引</em>的（为了保护客户的隐私，表名和部分列已经重命名）。SELECT /*+1*/nCHECKNUM AS PINGZBSM,nCHECKDATE,nXXXMODE,nXXXRESULT,n(SELECT RESULT nFROM (select ID,to_char(WMSYS.WM_CONCAT(xxxnu...
- MySQL in不走索引
- <em>优化</em>前SELECT*n FROM erp_helei mg WHERE mg.num = 602 n AND mg.pid n IN n (10002559,10002561,10002562,10002563,10002564,10002598,10002599,10002600,10002601,10002602,10002603,10002604,10002648,10002649,1000
- sql语句的where条件顺序和索引的顺序
- 建表CREATE TABLE `Problem_submit` (n `id` int(11) NOT NULL AUTO_INCREMENT,n `status` int(11) NOT NULL,n `user_id` int(11) NOT NULL,n `Username` varchar(30) NOT NULL,n `problem_id` int(11) NOT NULL,
- 由于mysql隐式类型转换导致的索引失效的问题
- 今天在测试执行计划时，发现了以下<em>问题</em>：nnnmy<em>sql</em> 1739 due to type or collation conversion on fieldnnnnnnuser表：nnnnnnn主键userId和userName上<em>分别</em>有主键<em>索引</em>和唯一<em>索引</em>。nnnn执行计划任务：nnnnnnn可以看到会执行全表扫描，并没有使用<em>索引</em>。nnn执行
- mysql 字段类型与索引的关系
- 1、<em>字段</em>是varchar类型，参数是int类型，不走<em>索引</em>rn2、<em>字段</em>是varchar类型，参数是字符串，走<em>索引</em>rn3、<em>字段</em>是int类型，参数是int类型，走<em>索引</em>rn4、<em>字段</em>是int类型，参数是字符串，走<em>索引</em>rn仅测试了my<em>sql</em> 5.1和5.6。
- mysql 联合索引 in查询是否生效
- 这篇文章主要讲的是使用in查询，联合<em>索引</em>是否会生效的<em>问题</em> n 首先简单说一下联合<em>索引</em>：联合<em>索引</em>又叫复合<em>索引</em>，是由表中的几个列联合组成的<em>索引</em>。联合<em>索引</em>生效需满足最左前缀原则，即如果联合<em>索引</em>列为a,b,c三列，a,b,c 、a,b 、a生效，b,c、a,c、b、c等不生效（此处的顺序不是where条件后面的先后顺序，而是where条件中是否存在这些列，如果where中只存在a,c列，...
- SQL优化之--日期时间段的读取
- 需求： n有一个职员历史表，表里有职员考勤组，生效开始日期，生效结束日期，然后我要取出指定时间段的考勤组。
- Mysql 索引问题-日期索引使用
- 最近在使用日期<em>索引</em>时，通过explain发现一直不走日期<em>索引</em>，在网上查询了下，发现使用过程中要注意以下情况：1、在查询数据条数约占总条数五分之一以下时能够使用到<em>索引</em>，但超过五分之一时，则使用全表扫描了。2、查询条件有日期<em>索引</em>和其他条件的话，只有所有条件都有<em>索引</em>的情况下，才会走日期<em>索引</em>，例如：WHERE stringId='1223333' and dayid &lt;='2018-03-15 00...
- nosql mongodb group分组统计及索引优化
- 最近在做mongodb的分析统计，发现group分组有多种做法，和<em>sql</em>还真是不太样，需要写点js代码，直接贴示例代码：这是我的collection，名字：t_user_score npublic class UserScore implements Serializable { n … n private Integer userId; n private BigDecimal userSc
- Mysql 强制使用索引 force index，提高sql查询效率
- 一、背景n之前写过一篇文章《oracle强制走<em>索引</em>，提高<em>sql</em>查询效率》：https://blog.csdn.net/weixin_41287692/article/details/79350991n由于现在使用 my<em>sql</em> 多一些，所以搜索了一下 my<em>sql</em> 是否也有类似的强制使用<em>索引</em>n二、使用方法nn语法nforce index(强制要走的那个<em>索引</em>)n示例nn强制使用<em>索引</em>前nSELECT *...
- MySQL SQL 优化案例：JOIN派生表
- <em>优化</em>之前：nSELECTn ap.institution_id,n date(ra.create_time) date,n sum(nnn IF (n ra.confirm_amount > ld.debit_amount,n ld.debit_amount,n ra.confirm_amountn )n ) return_
- Mysql连接查询时索引失效，字符集问题
- 关于My<em>sql</em>连接查询时<em>索引</em>失效的<em>问题</em>(字符集)开发过程中遇到一个<em>sql</em>,两张表a,b连接查询.a表数据量在3000左右，nb表数据量在1w左右，连接时使用b表主键可a中某<em>字段</em>进行相等连接na表全表扫描,b表通过主键连接EXPLAIN中row应为1,却显示1w,等于n每次连接都全表扫描a表,相当与共扫描行数3000*1w次,耗时很久.n原因排查过后发现两表字符集与排序规则均不相同n解决办法 使
- 数据库字段字符时进行区间查询
- 2018.1.18日当使用字符串进行连续的模糊查询时，or 需要加（）。or 和and相当于数字运算中的加法和乘法 <em>sql</em>条件在连接条件的时候会先算and两端的 在跟or两端的进行运算。select * from table where 1=1 and (xmmc like '%xxx%' or cgdw like '%xxxx%' or sheng like '%xxxx%') and 字符
- sqlserver sql调优 索引 （查询时间超过1分钟）根据时间匹配时超过1分钟
- 在项目 中往往遇到 数据过几十万百万不到的 数据 查询时延时很大，这种情况往往是很严重的<em>问题</em>，客户不可能点进去一个网页等你几分钟是吧?nn比如这条<em>sql</em> 在执行中往往遇到瓶颈，使用前面datapart 方法 使用两次 并没有第二个 between 要好 ，加<em>索引</em>后 我们发现nn不难发现 时间少了 3倍，但是这世间也是挺长的了24秒 能在快点嘛？？？nnn好，我们增加一个state 条
- 2017-12-05 DBA日记，mysql的datetime字段索引不能识别sysdate
- 一、案例描述rnrn今日在进行MYSQL日常检查时，发现有一条SQL语句，在<em>字段</em>类型为datetime并创建<em>索引</em>的情况下，进行between (sysdate()+interval(-1) hour) and sysdate()时并不会使用<em>索引</em>，但是用now()代替sysdate就可以使用<em>索引</em>，这是为什么呢？rnrn二、<em>问题</em>rnrn为什么datetime<em>字段</em>(已有且只有一个关键字的<em>索引</em>）与sysd
- MySQL查询中关联字段字符集不一致会导致查询放弃索引
- 起因nn这个一个填坑的时代，公司业务比较多，因业务发展需要，业务技术部门将系统的用户id由原来的int类型改成varchar类型，然后我负责的项目要依托于业务的用户id，所以我库里的用户id也相应的由int类型变更成varchar类型，但是，由于一时疏忽，我库里的表之前的开发人员设计的时候，把部分表字符集指定成utf8，而另一些表的字符集指定成utf8mb4，最后我在变更<em>字段</em>类型的时候，没统一<em>字段</em>...
- mysql 不走索引的情形
- nmy<em>sql</em> 不走<em>索引</em>的情形：rn1. null 值判断；rn2. != , &lt;&gt; 操作符；rn3. or(大多数情况下)；rn4. in（大多数情况下）；rn5. like的使用（大多数情况下）；rn6. where 子句中对<em>字段</em>进行表达式操作,eg： select id from t where num/2=100 ；rn7. 在 where 子句中对<em>字段</em>进行函数操作rn8. 在 ...
- MySql 索引字段太长
- MySql <em>索引</em><em>字段</em>太长n今天数据库执行 quartz <em>sql</em> 错误 Specified key was too long; max key length is 767 bytes。我采用的数据库字符集是 utf8mb4n解决如下：nALTER DATABASEdatabasenameCHARACTER SET utf8;nn...
- MySQL模糊搜索优化
- InnoDB引擎对FULLTEXT<em>索引</em>的支持是MySQL5.6新引入的特性，之前只有MyISAM引擎支持FULLTEXT<em>索引</em>。对于FULLTEXT<em>索引</em>的内容可以使用MATCH()…AGAINST语法进行查询。nn 全文搜索的语法：n MATCH(col1,col2,…) AGAINST (expr[search_modifier])。
- sql调优之添加索引
- 当数据库单表数据量非常大的时候，使用普通查询耗时非常多，默认会根据搜索条件全表扫描；添加<em>索引</em>后，查询时就会先去<em>索引</em>列表中一次定位到特定值的行数，大大减少遍历匹配的行数，所以能明显增加查询的速度。nn添加<em>索引</em>的话，首先去<em>索引</em>列表中查询，而我们的<em>索引</em>列表是B类树的数据结构，查询的时间复杂度为O(log2N)，定位到特定值得行就会非常快，所以其查询速度就会非常快。nn我们这里有一张表，有67万条数据nn...
- 子查询到底走不走索引？
- CREATE TABLE zichaxuntest (na int(11) NOT NULL,nb varchar(255) DEFAULT NULL,nc varchar(255) DEFAULT NULL,nd varchar(255) DEFAULT NULL,nPRIMARY KEY (a),nKEY bIndex (b) USING BTREEn) ENGINE=InnoDB DEFAU...
- MySQL字段为varchar类型和int类型索引的使用技巧
- MySQL<em>索引</em>使用：<em>字段</em>为varchar类型时，条件要使用' '包起来nn结论：nn当MySQL中<em>字段</em>为int类型时，搜索条件where num=‘111‘ 与where num=111都可以使用该<em>字段</em>的<em>索引</em>。n当MySQL中<em>字段</em>为varchar类型时，搜索条件where num=‘111‘ 可以使用<em>索引</em>，where num=111 不可以使用<em>索引</em>nn验证过程：nn 建表语句：nnnCREA...
- SQL SERVER 强制指定使用索引方法
- 在一些应用场景下，使用<em>索引</em>反而降低了查询效率。此时，希望能够通过一些方案自主控制什么时候使用<em>索引</em>，什么时候不使用<em>索引</em>。通过在网上查询相关资料，找到了一种使用 with语句的解决方案。具体介绍如下： ① 使用 "with INDEX('指定<em>索引</em>名称')"--指定使用PK_indexselect count(1)from table1 a with(nolock)join table2 b wit...
- 强连通分量及缩点tarjan算法解析
- 强连通分量： 简言之 就是找环（每条边只走一次，两两可达） 孤立的一个点也是一个连通分量 使用tarjan算法 在嵌套的多个环中优先得到最大环( 最小环就是每个孤立点） 定义： int Time, DFN[N], Low[N]; DFN[i]表示 遍历到 i 点时是第几次dfs Low[u] 表示 以u点为父节点的 子树 能连接到 [栈中] 最上端的点 int
- 读取cmos前64字节下载
- 用c语言把cmos信息的前64个字节的内容显示出来 相关下载链接：[url=//download.csdn.net/download/lfm111333/2383512?utm_source=bbsseo]//download.csdn.net/download/lfm111333/2383512?utm_source=bbsseo[/url]
- 用protues仿真的单片机DS18B20 数字温度传感器下载
- 用protues仿真的单片机DS18B20 数字温度传感器 用protues仿真的单片机DS18B20 数字温度传感器 相关下载链接：[url=//download.csdn.net/download/zhengdaobaozengna/2414171?utm_source=bbsseo]//download.csdn.net/download/zhengdaobaozengna/2414171?utm_source=bbsseo[/url]
- 使用css制作的菜单效果下载
- 纯用css实现的菜单效果，有多种效果可供选择。 相关下载链接：[url=//download.csdn.net/download/zero000/2548059?utm_source=bbsseo]//download.csdn.net/download/zero000/2548059?utm_source=bbsseo[/url]
我们是很有底线的