在MySQL中经常出现未按照理想情况使用索引的情况，今天记录一种Order by语句的使用导致未按预期使用索引的情况。 1....从SQL及索引情况来看，使用createDate字段的索引应该会更好才对，为验证此情况，使用force index来强制使用createDate索引运行一次查看结果。...2 各种不太合理尝试 2.1 强制使用索引 使用force index (createDate)是可以解决的，此方式上面已经测试过了 2.2 忽略不理想的索引 类似于force index，可以使用...2.3 添加组合索引 将payDate 及createDate 添加为组合索引，但是此举不是一个好办法，执行计划也未按理想情况运行。 3....例如createDate 如果范围很大，那么其实走payDate 的索引取前15条记录会更快，为了让应用改动最少且不会因为其他条件的变化而导致未能走合理的索引，选择另一种优化方案，将SQL改为如下情况：
对于索引的调整，我们可以通过Oracle提供的索引监控特性来跟踪索引是否被使用。尽管该特性并未提供索引使用的频度，但仍不失为我们参考的方式之一。...然而，最近在Oracle 10.2.0.3中发现收集统计信息时导致索引也被监控，而不是用于sql查询引发的索引监控。如此这般，索引监控岂不是鸡肋？...--可以看出，插入数据后，收集统计信息并不会导致索引被使用 SQL> select * from v$object_usage where index_name='T_PK'; INDEX_NAME...，在Oracle 10g中当收集统计信息时，如果当前索引的统计信息也被收集则导致该索引被监控 b、注意索引能否被收集到还依赖于estimate_percent以及method_opt等收集时的相关参数... c、由于上述情形存在因此索引监控在10g中功能有限，不过对于索引的使用情况也可以通过查询DBA_HIST_SQL_PLAN来获得 d、在Oracle 11g中，不会出现上述情况
网上经常能看到一些文章总结在 mysql 中不能命中索引的各种情况，其中有一种说法就是指使用了 or 的语句都不能命中索引。...这种说法其实是不够正确的，正确的结论应该是，从 mysql5.0 后，如果在 or 连接的字段上都有独立的索引的话，是可以命中索引的，这里就是用到了 index_merge 特性。...在 mysql5.0 版本以前一条 sql 只能选择使用一个索引，而且如果 sql 中使用了 or 关键字，那么已有的索引就会失效，会走全表扫描。...因为无论走哪个索引，mysql 都不能一次性查找出符合条件的数据，所以只能放弃索引。...mysql 也是一直在不断升级更新，所以在 mysql5.0 版本后，增加了 index_merge 索引合并这个特性，也因此支持了一条 sql 使用多个索引。
在创建索引时指定 background:true 可以在后台构建索引，不会加锁阻塞集合上的其它操作，这也是我们日常添加索引常用的方式。...当任何创建索引操作复制到 Secondary 时，应避免在集合上删除索引。...事情起因是主节点在同一个集合上执行创建索引和删除索引后，在从节点回放时出现了很严重的阻塞，大量的只读请求开始不断积压，最后导致 WT_SESSION 消耗殆尽，Server 无法与 WiredTiger...进行内部通信，最终导致实例 Crash。...3问题复现 下面的案例在测试环境复现 WT_SESSION 超过限制的情况，dropIndex 导致从节点锁阻塞的问题有兴趣可自己测试复现，这里就不做演示了。
今天和大家分享一个很有意思的例子，关于索引列的顺序导致的性能问题。...竟然导致CPU 99% 抓了一个explain plan 的report和自己的理解，先简单说明一下表的情况。...删除原来的索引，然后重新索引，按照指定的顺序来建立索引，立马进行验证，但失望的是性能指标并没有任何改变。 ?...重新建立索引，试着用create unique index的方式来建立索引，终于发现问题。 ? 问题基本找到了，然后建立主键，关联产生索引来看看，发现达到了预期的效果。逻辑读很低,cpu消耗也很低。...有的朋友可能说，是不是由于索引没有关联主键导致的这样的问题。如果建立索引还是按照PARTITION_KEY,NOTIFICATION_SEQ_NO 性能应该没有什么差别 ?
作为主要数据库的，后来由于一些业务上的原因从 MySQL 迁移到了 MongoDB，使用了几个月的时间后，由于数据库服务非常不稳定，再加上无人看管，同时 MongoDB 本身就是无 Schema 的数据库，最后导致数据库的脏数据问题非常严重...，否则会导致父模型在获取自己持有的全部子模型时造成全表扫描： ?...Mongoid 的『小兄弟』们 在使用 Mongoid 进行开发期间难免会用到一些相关插件，比如 mongoid-enum、mongoid-slug 和 mongoid-history 等，这些插件的实现与...注意：要为每一张表添加类型为字符串的 uuid 字段，同时为 uuid 建立唯一索引，以加快通过 uuid 建立不同数据模型之间关系的速度。...MongoDB 和 MySQL 之间的选择也不一定是非此即彼，我们将项目中的大部分数据都迁移到了 MySQL 中，但是将一部分用于计算和分析的数据留在了 MongoDB，这样就可以保证 MongoDB 宕机之后仍然不会影响项目的主要任务
索引从 1 开始编号，顺序与表的 SHOW INDEX 所示顺序相同。索引映射值 N 是一个位掩码值，指示哪些索引是候选索引。...原因 在SQL的关联条件中，关联字段类型相同，并不是隐式类型转换问题导致无法命中索引，那么我们开始排查两表的字符集、排序规则是否一致。...(cast())，那么就相当于在查询SQL语句中使用了类型函数，导致无法命中索引。...但这种方案属于DDL操作，会阻塞INSERT、UPDATE、DELETE此类DML操作，若DDL阻塞时间过长，则可能会导致MySQL宕机，服务不可用。该方案在生产环境不推荐。...知识扩展 MySQL隐式转换导致无法命重索引的情况： If one or both arguments are NULL, the result of the comparison is NULL,
,这个组合索引并不是真正的稀疏索引,根据稀疏索引定义来讲,稀疏索引中不包括不存在字段的文档,但是这个是组合索引，但ut日期字段一直都在.所以此稀疏索引中还是索引key对应文档信息，只是缺少billSt字段而已...,所以说此组合是伪稀疏索引.从mongo 3.2开始推荐使用部分索引,因为部分索引提供稀疏索引的超集功能.此处应该创建部分索引能够更好实现稀疏索引功能且只保存条件索引key，从而实现之前创建稀疏的目的，...)导致性能问题(根据索引特性可以直接判断此索引是低效的) 低效表现:(keysExamined:2528071,nReturned:0)，接下来分析为什么这个所以性能低。...总结 虽然本次优化很简单，主要存在问题: 第一对于稀疏索引的理解，如果单列稀疏索引的话，索引列被移除的，那么稀疏索引则不包括索引列对应的文档，符合稀疏索引的预期行为...第二如果只是对满足条件记录进行索引且少量时（无其他不同查询），此时使用部分索引，部分索引是具有稀疏索引超级功能。
= 或者 导致索引失效 SELECT * FROM `user` WHERE `name` != '冰峰'; 我们给name字段建立了索引，但是如果!...2、类型不一致导致的索引失效 在说这个之前，一定要说一下设计表字段的时候，千万、一定、必须要保持字段类型的一致性，啥意思？...3、函数导致的索引失效 SELECT * FROM `user` WHERE DATE(create_time) = '2020-09-03'; 如果你的索引字段使用了索引，对不起，他是真的不走索引的...4、运算符导致的索引失效 SELECT * FROM `user` WHERE age - 1 = 20; 如果你对列进行了（+，-，*，/，!）, 那么都将不会走索引。 ?...关于符合索引导致索引失效的情况能说的目前就这两种，其实我觉得对于符合索引来说，重要的是如何建立高效的索引，千万不能说我用到那个字段我就去建立一个单独的索引，不是就可以全局用了嘛。
当初写这个SQL的开发人员，本意是想按天统计当下所有门店的一个销量情况，但是错就错在，他先在外层将所有区域查出来，再放到统计SQL的IN语句里面，这样就会导致索引失效。 ...a.store_id in (select store_id from store_table where is_del = 0) group by a.sku_id,a.store_id MySQL中IN数据范围不同导致索引使用不同...eq_ref：主键索引 (primary key) 或者非空唯一索引 (unique not null) 等值扫描 ref：非主键非唯一索引等值扫描（查找条件列使用了索引而且不为主键和unique。）...当IN多个主键时： 结果：type:range，此时仍然走了索引，但是效率降低了。 当IN范围继续扩大时： 结果：type：all，没有走索引了，而是全表扫描。...结论：IN肯定会走索引，但是当IN的取值范围较大时会导致索引失效，走全表扫描。 原因是：mysql有个阈值，决定了阈值之下使用索引查询，而超过阈值则退化，优化器选择索引下潜。
场景简介 SQL明明可以走a索引,却走了慢的b索引?...目的是考虑有些表数据量大，并且辅助索引多时，执行这些操作可能会比较慢，而使用者可能并不需要更新 Cardinality。 3、统计信息不准确导致选错索引 在 MySQL 中，优化器控制着索引的选择。...而从上面说到 Cardinality 的更新原理可以看出，它的值不一定准确的，因此有时可能就是因为它的值不精准导致选错了索引。...这种情况可以使用下面的命令重新统计信息： analyze table t13; 4、单次选取的数据量过大导致选错索引 有时，我们也会遇到这种情况，如果单次选取的数据量过大，可能也会导致 “选错” 索引。...另外举例说明了单次选取的数据量过大也有可能导致优化器选错索引，这种时候，可以尝试使用 force index 让 sql 强制走某个索引。
，并且引发了连接数暴增，导致数据库响应缓慢，影响业务。...而表是千万级别，并且该查询条件最后实际是返回的空数据，也就是MySQL在主键索引上实际检索时间很长，导致了慢查询。...而这次代码中查询条件实际结果为空，导致了扫描了全部的主键索引。 解决方案 知道了MySQL为何选择这个索引的原因后，我们就可以根据上面的思路来列举出解决办法了。...总结 本文带大家回顾了一次MySQL优化器选错索引导致的线上慢查询事故，可以看出MySQL优化器对于索引的选择并不单单依靠某一个标准，而是一个综合选择的结果。...最后做个文章总结： 该慢查询语句中使用order by id导致优化器在主键索引和city_id和type的联合索引中有所取舍，最终导致选择了更慢的索引。
profiling的结果输出含义在这里，多看官网文档 CPU杀手1：全表扫描 全集合（表）扫描 COLLSCAN，当一个查询（或更新、删除）请求需要全表扫描时，是非常耗CPU资源的，所以当你在 system.profile...集合 或者 日志文件发现 COLLSCAN 关键字时，就得注意了，很可能就是这些查询吃掉了你的 CPU 资源；确认一下，如果这种请求比较频繁，最好是针对查询的字段建立索引来优化。...> 关键字：COLLSCAN、 docsExamined CPU杀手2：不合理的索引 有的时候，请求即使查询走了索引，执行也很慢，通常是因为合理建立不太合理（或者是匹配的结果本身就很多，这样即使走索引，...资源的，优化的方法仍然是建立索引，对经常需要排序的字段，建立索引。...当你在 system.profile 集合 或者 日志文件发现 SORT 关键字时，就可以考虑通过索引来优化排序。
如果是全表扫描，则是COLLSCAN "keysExamined": 20856, // 该项表明为了找出最终结果MongoDB搜索了索引中的多少个key "docsExamined":...writeConflicts 写冲突次数 写是要加写锁的，如果写冲突次数很多，比如多个操作同时更新同一个文档，可能会导致该操作耗时较长，主要就消耗在写冲突这里了。...planSummary 执行计划 这里表示MongoDB是怎么去取数据的，有以下几种类型： COLLSCAN —— 全表扫描 IXSCAN —— 索引扫描 IDHACK —— 使用了默认的_id索引 FETCH...如果遇到COLLSCAN导致的慢查询的话，可以考虑新建相应的索引来优化查询了。...该字段后面会输出具体使用的哪一个索引。有可能一个表有多个索引，当这里的索引不符合预期时，也应该考虑优化索引或者通过hint()来改造查询语句。
问题描述 检查腾讯云数据库 MySQL 实例的 CPU 使用率情况，如果MongoDB实例的CPU使⽤率过⾼，会导致MonogoDB响应缓慢，甚⾄业务不可⽤。...请关注：command、COLLSCAN、IXSCAN、keysExamined、docsExamined 等关键字 需注意的关键字如下： command 指出慢日志中记录的操作。...COLLSCAN 代表该查询进行了全表扫描(全表扫描说明没有用上索引，或者优化器认为索引扫描的效率更低)，IXSCAN 代表进行了索引扫描。...keysExamined 代表索引扫描条目，docsExamined 代表文档扫描条目。keysExamined 和 docsExamined 越大代表没有建索引或者索引的区分度不高。...如果是并发过⾼导致了CPU占用高的问题，在云数据库MongoDB可以通过扩容CPU来解决： 1、通过升级配置来增加云数据库的读写能力 登录 MongoDB 控制台。
之前的一篇文件中《分析MySQL中隐式转换导致查询结果错误及索引不可用》分析了MySQL中隐式转换导致索引不可用的问题，最近又遇到一个索引不可用的案例； 1、问题背景 最近在使用MySQL上面发现了这样一个问题...但是为什么表字符集不一样（实际是字段字符集不一样）就会导致wt1全表扫描呢？...这里需要做字符集转换，字符集转换遵循由小到大的原则，因为utf8mb4是utf8的超集，所以这里把utf8转换成utf8mb4，即把wt1.code转换成utf8mb4字符集，转换了之后，由于wt1.code上面的索引仍然是...有人可能会说用alter table wt1 charset utf8mb4;但这是错的，这只是改了表的默认字符集，即新的字段才会使用utf8mb4，已经存在的字段仍然是utf8。...`name` = 'dddd') 1 row in set (0.00 sec) 4、注意点 （1）表字符集不同时，可能导致join的SQL使用不到索引，引起严重的性能问题； （2）SQL上线前要做好
为了验证 MySQL 中哪些情况下会导致索引失效，我们可以借助 explain 执行计划来分析索引失效的具体场景。...如果为 NULL 则表示未使用索引，反之则使用了索引。...MySQL 提供的函数就会导致索引失效，比如以下列使用了 ifnull 函数之后的执行计划如下： 索引失效情况5：类型转换 如果索引列存在类型转换，那么也不会走索引，比如 address 为字符串类型...，而查询的时候设置了 int 类型的值就会导致索引失效，如下图所示： 索引失效情况6：使用 is not null 当在查询中使用了 is not null 也会导致索引失效，而 is null...则会正常触发索引的，如下图所示： 总结 导致 MySQL 索引失效的常见场景有以下 6 种： 联合索引不满足最左匹配原则。
今天看到《删除分区如何不让全局索引失效？》这篇文章有朋友提了个问题， ?...官方文档，已经明确指出，除非使用update indexes，否则用truncate分区表，就会导致全局索引失效，必须重建， Unless you specify UPDATE INDEXES, any...扩展一下，对堆表来说，alter table不带update indexes，则涉及的局部索引会失效，涉及的全局索引会标记为失效，需要重建，对索引组织表，局部索引的效果和堆表相同，但是全局索引仍可用，...分区表执行drop、truncate、exchange这些DDL操作，不再是快速操作，他的时间就需要衡量了，因为会导致全局索引的失效，需要重建索引， The DROP, TRUNCATE, and EXCHANGE...创建全局索引， SQL> create index idx_01 on interval_sale(cust_id); Index created.
1 MongoDB 慢查询 MongoDB 响应慢，可能大部分原因是慢查询导致的，这里通过一个实验来聊聊 MongoDB 慢查询。...29998.0 }, lsid: { id: UUID("7529eb75-cffa-4164-a8d4-e4730d735c2b") }, $db: "martin" } planSummary: COLLSCAN...acquireCount: { r: 1 } } } storage:{} protocol:op_msg 142ms 其中： command 表示使用的命令； planSummary 表示执行计划； COLLSCAN...表示全表扫描； COLLSCAN 中的 keysExamined 表示是否走索引； COLLSCAN 中的 docsExamined 表示扫描文档数（类似MySQL的扫描行数）； locks 锁相关信息...表示使用了多少虚拟内存； res 表示实际使用的内存大小，如果内存使用的比较大，需要确定是否需要增加内存； qrw 表示读写等待的队列长度； arw 执行读写操作的活跃客户端数，看是否是短时间活跃连接数突增导致的响应变慢
options) options 分为3中模式： queryPlanner （默认）详细模式运行 executionStats allPlansExecution Stage状态分析 stage 描述 COLLSCAN...全表扫描 IXSCAN 扫描索引 FETCH 根据索引去检索指定document SHARD_MERGE 将各个分片返回数据进行merge SORT 表明在内存中进行了排序 LIMIT 使用limit...count运算 COUNTSCAN count不使用Index进行count时的stage返回 COUNT_SCAN count使用了Index进行count时的stage返回 SUBPLA 未使用到索引的...$or查询的stage返回 TEXT 使用全文索引进行查询时候的stage返回 PROJECTION 限定返回字段时候stage的返回 对于普通查询，我希望看到stage的组合(查询的时候尽可能用上索引...Fetch+ixscan Limit+（Fetch+ixscan） PROJECTION+ixscan SHARDING_FITER+ixscan COUNT_SCAN 不希望看到包含如下的stage： COLLSCAN
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
云直播
实时音视频
