如何完成一次快速的查询 - 从MySQL到分库分表到ES和HBASE

本文探讨了MySQL查询慢的原因,包括索引失效、MDL锁、flush等待、行锁和大表场景下的分库分表与读写分离。接着介绍了Elasticsearch的快速查询机制和适用场景,并分析了HBase的存储结构和应用场景。总结了在不同场景下选择合适的技术来完成快速查询的重要性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

哪个男孩不想完成一次快速的查询?

1. MySQL 查询慢是什么体验?

谢邀,利益相关。

大多数互联网应用场景都是读多写少,业务逻辑更多分布在写上。对读的要求大概就是要快。那么都有什么原因会导致我们完成一次出色的慢查询呢?

1.1 索引

在数据量不是很大时,大多慢查询可以用索引解决,大多慢查询也因为索引不合理而产生。

MySQL 索引基于 B+ 树,这句话相信面试都背烂了,接着就可以问最左前缀索引、 B+ 树和各种树了。

说到最左前缀,实际就是组合索引的使用规则,使用合理组合索引可以有效的提高查询速度,为什么呢?

因为索引下推。如果查询条件包含在了组合索引中,比如存在组合索引(a,b),查询到满足 a 的记录后会直接在索引内部判断 b 是否满足,减少回表次数。同时,如果查询的列恰好包含在组合索引中,即为覆盖索引,无需回表。
索引规则估计都知道,实际开发中也会创建和使用。 问题可能更多的是:为什么建了索引还慢?

1.1.1 什么原因导致索引失效

建了索引还慢,多半是索引失效(未使用),可用 explain 分析。索引失效常见原因有 :

  1. where 中使用 != 或 <> 或 or 或表达式或函数(左侧)
  2. like 语句 % 开头
  3. 字符串未加’’
  4. 索引字段区分度过低,如性别
  5. 未匹配最左前缀

(一张嘴就知道老面试题了) 为什么这些做法会导致失效,成熟的 MySQL 也有自己的想法。

1.1.2 这些原因为什么导致索引失效

如果要 MySQL 给一个理由,还是那棵 B+ 树。

函数操作

当在 查询 where = 左侧使用表达式或函数时,如字段 A 为字符串型且有索引, 有 where length(a) = 6查询,这时传递一个 6 到 A 的索引树,不难想象在树的第一层就迷路了。

隐式转换

隐式类型转换和隐式字符编码转换也会导致这个问题。

  • 隐式类型转换对于 JOOQ 这种框架来说一般倒不会出现。
  • 隐式字符编码转换在连表查询时倒可能出现,即连表字段的类型相同但字符编码不同。
破坏了有序性

至于 Like 语句 % 开头、字符串未加 ’’ 原因基本一致,MySQL 认为对索引字段的操作可能会破坏索引有序性就机智的优化掉了。

不过,对于如性别这种区分度过低的字段,索引失效就不是因为这个原因。

1.1.3 性别字段为什么不要加索引

为什么索引区分度低的字段不要加索引。盲猜效率低,效率的确低,有时甚至会等于没加。

对于非聚簇索引,是要回表的。假如有 100 条数据,在 sex 字段建立索引,扫描到 51 个 male,需要再回表扫描 51 行。还不如直接来一次全表扫描呢。

所以,InnoDB 引擎对于这种场景就会放弃使用索引,至于区分度多低多少会放弃,大致是某类型的数据占到总的 30% 左右时,就会放弃使用该字段的索引,有兴趣可以试一下。

1.1.4 有什么好用且简单的索引方法

前面说到大多慢查询都源于索引,怎么建立并用好索引。这里有一些简单的规则。

  • 索引下推:性别字段不适合建索引,但确实存在查询场景怎么办?如果是多条件查询,可以建立联合索引利用该特性优化。

  • 覆盖索引:也是联合索引,查询需要的信息在索引里已经包含了,就不会再回表了。

  • 前缀索引:对于字符串,可以只在前 N 位添加索引,避免不必要的开支。假如的确需要如关键字查询,那交给更合适的如 ES 或许更好。

  • 不要对索引字段做函数操作

  • 对于确定的、写多读少的表或者频繁更新的字段都应该考虑索引的维护成本。

1.1.5 如何评价 MySQL 选错了索引

有时,建立了猛一看挺正确的索引,但事情却没按计划发展。就像“为啥 XXX 有索引,根据它查询还是慢查询”。

此刻没准要自信点:我的代码不可能有 BUG,肯定是 MySQL 出了问题。MySQL 的确可能有点问题。

这种情况常见于建了一大堆索引,查询条件一大堆。没使用你想让它用的那一个,而是选了个区分度低的,导致过多的扫描。造成的原因基本有两个:

  • 信息统计不准确:可以使用 analyze table x重新分析。

  • 优化器误判:可以 force index强制指定。或修改语句引导优化器,增加或删除索引绕过。

但根据我浅薄的经验来看,更可能是因为你建了些没必要的索引导致的。不会真有人以为 MySQL 没自己机灵吧?

除了上面这些索引原因外,还有下面这些不常见或者说不好判断的原因存在。

1.2 等MDL锁

在 MySQL 5.5 版本中引入了 MDL,对一个表做 CRUD 操作时,自动加 MDL 读锁;对表结构做变更时,加 MDL 写锁。读写锁、写锁间互斥。

当某语句拿 MDL 写锁就会阻塞 MDL 读锁,可以使用show processlist命令查看处于Waiting for table metadata lock状态的语句。

1.3 等 flush

flush 很快,大多是因为 flush 命令被别的语句堵住,它又堵住了 select 。通过show processlist命令查看时会发

<think>好的,用户想比较Elasticsearch传统关系型数据库的功能适用场景。首先,我需要回顾这两者的核心特点差异。关系型数据库,比如MySQL或PostgreSQL,基于结构化数据模型,使用SQL进行查询,支持ACID事务,适合需要复杂查询事务处理的场景。而Elasticsearch是一个基于Lucene的分布式搜索引擎,擅长全文搜索、实时分析处理非结构化数据。 接下来,用户可能需要了解它们在不同方面的对比,比如数据模型、查询能力、扩展性、事务支持等。根据引用中的内容,传统数据库依赖统计信息进行查询优化[^1],而Elasticsearch更适合变化快且数据量适中的场景[^2]。此外,引用提到不同的NoSQL数据库在扩展性上的差异,比如HBase更适合大规模数据[^3],这可能间接说明Elasticsearch在扩展性上的表现。 还要注意数据类型支持,传统数据库有严格的类型定义如INTEGER、REAL等[^4],而Elasticsearch更灵活,支持动态映射。适用场景方面,Elasticsearch适用于日志分析、全文搜索,而关系数据库适合事务处理、复杂连接操作。 用户可能还想知道何时选择其中一种而非另一种,或者如何结合使用。需要指出两者的优缺点,帮助用户根据具体需求做出决策。例如,高事务需求用关系型,搜索分析用Elasticsearch,并提到混合架构的可能性。 最后,根据用户提供的引用,确保在回答中正确引用相关内容,比如数据库统计信息的重要性,适用场景的数据变化大小[^2],以及扩展性差异[^3]。同时,检是否有遗漏的关键点,比如ACID支持、分布式架构、实时性等,确保回答全面且结构清晰。</think>### Elasticsearch与关系型数据库对比分析 #### 一、核心功能差异 1. **数据模型** - 关系型数据库:采用严格的二维表结构,支持主键约束、外键关联范式化设计,数据类型需预先定义(如`INTEGER32`、`FLOAT32`等)。 - Elasticsearch:基于JSON文档的灵活模式(Schema-less),支持动态字段映射,适合非结构化数据。 2. **查询能力** - 关系型数据库:擅长复杂SQL查询(如多表`JOIN`、聚合函数),依赖统计信息优化执行计划[^1]。 - Elasticsearch:专精全文检索、模糊匹配近实时分析,支持分词、相关性评分地理空间查询。 3. **事务与一致性** - 关系型数据库:支持ACID事务,保证数据强一致性。 - Elasticsearch:仅保证最终一致性,写入延迟通常为1秒(通过`refresh_interval`配置)。 #### 二、性能与扩展性 1. **写入性能** - 关系型数据库:受事务锁磁盘I/O限制,适用于中等写入吞吐量。 - Elasticsearch:采用倒排索引分片机制,写入速度更快,适合日志流等高频写入场景。 2. **扩展模式** - 关系型数据库:垂直扩展为主,水平扩展需分库分表- Elasticsearch:原生分布式架构,支持自动分片跨节点负载均衡,但数据规模超过PB级时扩展效率低于HBase等系统。 #### 三、典型应用场景 | 场景 | 关系型数据库 | Elasticsearch | |---------------------|---------------------------|---------------------------------| | 金融交易系统 | ✅ 事务处理 | ❌ | | 电商商品搜索 | ❌ 模糊查询效率低 | ✅ 支持多字段加权排序 | | 日志分析与监控 | ❌ 海量数据聚合性能差 | ✅ 结合Kibana实现可视化分析 | | 社交网络关系管理 | ✅ 多表关联查询 | ❌ 缺乏JOIN支持 | #### 四、混合架构实践 许多系统采用组合方案: 1. 使用关系型数据库作为**主数据存储**,保障事务完整性。 2. 通过ETL工具将需要搜索/分析的数据同步到Elasticsearch。 3. 在查询层根据请求类型路由到不同引擎(如精确查询数据库,全文检索走ES)。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值