今日推荐
1. MySQL查询慢是什么体验?
大多数互联网应用场景都是读多写少,业务逻辑更多分布在写上。对读的要求大概就是要快。那么都有什么原因会导致我们完成一次出色的慢查询呢?
1.1 索引
在数据量不是很大时,大多慢查询可以用索引解决,大多慢查询也因为索引不合理而产生。
MySQL 索引基于 B+ 树,这句话相信面试都背烂了,接着就可以问最左前缀索引、 B+ 树和各种树了。
说到最左前缀,实际就是组合索引的使用规则,使用合理组合索引可以有效的提高查询速度,为什么呢?
因为索引下推。如果查询条件包含在了组合索引中,比如存在组合索引(a,b),查询到满足 a 的记录后会直接在索引内部判断 b 是否满足,减少回表次数。同时,如果查询的列恰好包含在组合索引中,即为覆盖索引,无需回表。索引规则估计都知道,实际开发中也会创建和使用。问题可能更多的是:为什么建了索引还慢?
1.1.1 什么原因导致索引失效
建了索引还慢,多半是索引失效(未使用),可用 explain 分析。索引失效常见原因有 :
where 中使用 != 或 <> 或 or 或表达式或函数(左侧) like 语句 % 开头 字符串未加’’ 索引字段区分度过低,如性别 未匹配最左前缀
1.1.2 这些原因为什么导致索引失效
函数操作
where length(a) = 6
查询,这时传递一个 6 到 A 的索引树,不难想象在树的第一层就迷路了。隐式转换
隐式类型转换对于 JOOQ 这种框架来说一般倒不会出现。 隐式字符编码转换在连表查询时倒可能出现,即连表字段的类型相同但字符编码不同。
破坏了有序性
1.1.3 性别字段为什么不要加索引
为什么索引区分度低的字段不要加索引。盲猜效率低,效率的确低,有时甚至会等于没加。
1.1.4 有什么好用且简单的索引方法
索引下推:性别字段不适合建索引,但确实存在查询场景怎么办?如果是多条件查询,可以建立联合索引利用该特性优化。 覆盖索引:也是联合索引,查询需要的信息在索引里已经包含了,就不会再回表了。 前缀索引:对于字符串,可以只在前 N 位添加索引,避免不必要的开支。假如的确需要如关键字查询,那交给更合适的如 ES 或许更好。 不要对索引字段做函数操作 对于确定的、写多读少的表或者频繁更新的字段都应该考虑索引的维护成本。
1.1.5 如何评价 MySQL 选错了索引
信息统计不准确:可以使用 analyze table x
重新分析。优化器误判:可以 force index
强制指定。或修改语句引导优化器,增加或删除索引绕过。
1.2 等MDL锁
show processlist
命令查看处于Waiting for table metadata lock
状态的语句。1.3 等 flush
show processlist
命令查看时会发现处于Waiting for table flush
状态。1.4 等行锁
1.5 当前读
1.6 大表场景
1.6.1 分库分表
方案
如果磁盘或网络有 IO 瓶颈,那就要分库和垂直分表。 如果是 CPU 瓶颈,即查询效率偏低,水平分表。
水平即切分数据,分散原有数据到更多的库表中。 垂直即按照业务对库,按字段对表切分。
问题
唯一 ID 方法很多,DB 自增、Snowflake、号段、一大波GUID算法等。 非 partition key 查询常用映射法解决,映射表用到覆盖索引的话还是很快的。或者可以和其他 DB 组合。 扩容要根据分片时的策略确定,范围分片的话就很简单,而随机取模分片就要迁移数据了。也可以用范围 + 取模的模式分片,先取模再范围,可以避免一定程度的数据迁移。
1.6.2 读写分离
为什么要读写分离
问题
过期读,也就是主从延时问题,这个对于。 分配机制,是走主还是从库。可以直接代码中根据语句类型切换或者使用中间件。
1.7 小结
2. 如何评价 ElasticSearch
GET yourIndex/_search
{
"from" : 0, "size" : 10,
"query" : {
"match_phrase" : {
"log" : "xxx"
}
}
}
2.2 ES 的结构
GET /_cat/health?v&pretty:查看集群健康状态 GET /_cat/shards?v :查看分片状态 GET yourindex/_mapping :index mapping结构 GET yourindex/_settings :index setting结构 GET /_cat/indices?v :查看当前节点所有索引信息
"******": {
"mappings": {
"doc": {
"properties": {
"appname": {
"type": "text",
"fields": {
"keyword": {
"type": "keyword",
"ignore_above": 256
}
}
2.3 ES 查询为什么快?
2.3.1 分词后检索
POST yourindex/_analyze
{
"field":"yourfield",
"text":"我可真是个机灵鬼"
}
2.4.2 组合查询
1. ES + MySQL
2. ES + HBASE
3. HBASE
下图是一个 HBASE 实际的表模型结构。
Row key 是主键,按照字典序排序。TimeStamp 是版本号。info 和 area 都是列簇(column Family),列簇将表进行横向切割。name、age 叫做列,属于某一个列簇,可进行动态添加。Cell 是具体的 Value 。
3.2 OLTP 和 OLAP
OLTP是传统的关系型数据库的主要应用,主要是基本的、日常的事务处理。 OLAP是数据仓库系统的主要应用,支持复杂分析,侧重决策支持,提供直观易懂的查询结果。
4. 总结
作者:llc687
https://llc687.top/post/如何完成一次快速的查询
参考
推荐文章
更多项目源码