返回顶部
首页 > 资讯 > 数据库 >MYSQL5.6 5.7处理数据分布不均的问题分析
  • 873
分享到

MYSQL5.6 5.7处理数据分布不均的问题分析

2024-04-02 19:04:59 873人浏览 安东尼
摘要

本篇内容主要讲解“Mysql5.6 5.7处理数据分布不均的问题分析”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“mysql5.6 5.7处理数据分布不均的问题

本篇内容主要讲解“Mysql5.6 5.7处理数据分布不均的问题分析”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习mysql5.6 5.7处理数据分布不均的问题分析”吧!

处理数据分布不均,orace数据库使用额外的统计数据直方图来完成,而MYsql
中统计数据只有索引的不同值这样一个统计数据,那么我们制出如下数据:
mysql> select * from test.testf;
+------+----------+
| id   | name     |
+------+----------+
|    1 | gaopeng  |
|    2 | gaopeng1 |
|    3 | gaopeng1 |
|    4 | gaopeng1 |
|    5 | gaopeng1 |
|    6 | gaopeng1 |
|    7 | gaopeng1 |
|    8 | gaopeng1 |
|    9 | gaopeng1 |
|   10 | gaopeng1 |
+------+----------+
10 rows in set (0.00 sec)
name 上有一个普通二级索引
mysql> analyze table test.testf;
+------------+---------+----------+----------+
| Table      | Op      | Msg_type | Msg_text |
+------------+---------+----------+----------+
| test.testf | analyze | status   | OK       |
+------------+---------+----------+----------+
1 row in set (0.21 sec)

分别作出如下执行计划:
mysql> explain select * from test.testf where name='gaopeng';
+----+-------------+-------+------------+------+---------------+------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref   | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+------+---------+-------+------+----------+-------+
|  1 | SIMPLE      | testf | NULL       | ref  | name          | name | 63      | const |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+------+---------------+------+---------+-------+------+----------+-------+
1 row in set, 1 warning (0.00 sec)

mysql> explain select * from test.testf where name='gaopeng1';
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | testf | NULL       | ALL  | name          | NULL | NULL    | NULL |   10 |    90.00 | Using where |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
1 row in set, 1 warning (0.00 sec)

可以看到执行计划是正确的,name='gaopeng'的只有一行选择了索引,name='gaopeng1'的有9行走了全表。
按理说如果只是记录不同的那么这两个语句的选择均为1/2,应该会造成执行计划错误,而MYSQL 5.6 5.7中
都做了正确的选择,那是为什么呢?
其实原因就在于 eq_range_index_dive_limit这个参数,我们来看一下trace
T@2: | | | | | | | | | | | opt: (null): "gaopeng1 <= name <=  | T@3: | | | | | | | | | | | opt: (null): "gaopeng <= name <= g
T@2: | | | | | | | | | | | opt: ranges: ending struct         | T@3: | | | | | | | | | | | opt: ranges: ending struct
T@2: | | | | | | | | | | | opt: index_dives_for_eq_ranges: 1  | T@3: | | | | | | | | | | | opt: index_dives_for_eq_ranges: 1
T@2: | | | | | | | | | | | opt: rowid_ordered: 1              | T@3: | | | | | | | | | | | opt: rowid_ordered: 1
T@2: | | | | | | | | | | | opt: using_mrr: 0                  | T@3: | | | | | | | | | | | opt: using_mrr: 0
T@2: | | | | | | | | | | | opt: index_only: 0                 | T@3: | | | | | | | | | | | opt: index_only: 0
T@2: | | | | | | | | | | | opt: rows: 9                       | T@3: | | | | | | | | | | | opt: rows: 1
T@2: | | | | | | | | | | | opt: cost: 11.81                   | T@3: | | | | | | | | | | | opt: cost: 2.21


我们可以看到 index_dives_for_eq_ranges均为1,rows: 9 rows: 1都是正确的,那么可以确定是index_dives_for_eq_ranges的作用,实际上
这是一个参数eq_range_index_dive_limit来决定的(equality range optimization of many-valued comparisions),默认为
mysql> show variables like '%eq%';
+--------------------------------------+-------+
| Variable_name                        | Value |
+--------------------------------------+-------+
| eq_range_index_dive_limit            | 200   |

在官方文档说这个取值是等值范围比较的时候有多少个需要比较的值
如:
id=1 or id=2 or id=3 那么他取值就是3+1=4
而这种方法会得到精确的数据,但是增加的是时间成本,如果将
eq_range_index_dive_limit 设置为1:则禁用此功能
eq_range_index_dive_limit 设置为0:则始终开启
eq_range_index_dive_limit 设置为N:则满足N-1个这样的域。
那么我们设置为eq_range_index_dive_limit=1 后看看
mysql> explain select * from test.testf where name='gaopeng1';
+----+-------------+-------+------------+------+---------------+------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref   | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+------+---------+-------+------+----------+-------+
|  1 | SIMPLE      | testf | NULL       | ref  | name          | name | 63      | const |    5 |   100.00 | NULL  |
+----+-------------+-------+------------+------+---------------+------+---------+-------+------+----------+-------+
1 row in set, 1 warning (0.00 sec)


mysql> explain select * from test.testf where name='gaopeng';
+----+-------------+-------+------------+------+---------------+------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref   | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+------+---------+-------+------+----------+-------+
|  1 | SIMPLE      | testf | NULL       | ref  | name          | name | 63      | const |    5 |   100.00 | NULL  |
+----+-------------+-------+------------+------+---------------+------+---------+-------+------+----------+-------+
1 row in set, 1 warning (0.00 sec)

可以看到执行计划已经错误 name='gaopeng1' 明显不应该使用索引,我们再来看看trace
T@3: | | | | | | | | | | | opt: ranges: ending struct
T@3: | | | | | | | | | | | opt: index_dives_for_eq_ranges: 0
T@3: | | | | | | | | | | | opt: rowid_ordered: 1
T@3: | | | | | | | | | | | opt: using_mrr: 0
T@3: | | | | | | | | | | | opt: index_only: 0
T@3: | | | | | | | | | | | opt: rows: 5
T@3: | | | | | | | | | | | opt: cost: 7.01
index_dives_for_eq_ranges: 0 rows: 5这个5就是10*1/2导致的,而index_dives_for_eq_ranges=0就是禁用了

到此,相信大家对“MYSQL5.6 5.7处理数据分布不均的问题分析”有了更深的了解,不妨来实际操作一番吧!这里是编程网网站,更多相关内容可以进入相关频道进行查询,关注我们,继续学习!

您可能感兴趣的文档:

--结束END--

本文标题: MYSQL5.6 5.7处理数据分布不均的问题分析

本文链接: https://lsjlt.com/news/66751.html(转载时请注明来源链接)

有问题或投稿请发送至: 邮箱/279061341@qq.com    QQ/279061341

猜你喜欢
  • MYSQL5.6 5.7处理数据分布不均的问题分析
    本篇内容主要讲解“MYSQL5.6 5.7处理数据分布不均的问题分析”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“MYSQL5.6 5.7处理数据分布不均的问题...
    99+
    2024-04-02
  • HBase如何处理数据的分布和负载均衡
    HBase处理数据的分布和负载均衡主要通过以下方式: 分布式存储:HBase采用分布式存储的方式来存储数据,数据被分散存储在多个...
    99+
    2024-04-09
    HBase
  • WMS问题处理的示例分析
    这篇文章主要介绍了WMS问题处理的示例分析,具有一定借鉴价值,感兴趣的朋友可以参考下,希望大家阅读完这篇文章之后大有收获,下面让小编带着大家一起了解一下。采购订单没有生成上传订单号pkg_inpurchas...
    99+
    2024-04-02
  • HBase如何处理数据的分布式存储和负载均衡
    在HBase中,数据的分布式存储和负载均衡是由HBase中的HMaster和RegionServer来实现的。 HBase集群中有一...
    99+
    2024-03-11
    HBase
  • 大数据处理需不需要分布式架构?
    随着数据量的不断增加,大数据处理已经成为了许多企业和组织所面临的一个重要问题。而对于大数据处理来说,分布式架构已经变得越来越重要。那么,大数据处理需不需要分布式架构呢?这是一个值得探讨的话题。 首先,让我们来了解一下什么是分布式架构。分布式...
    99+
    2023-09-15
    大数据 分布式 apache
  • MySQL主从不同步问题分析与处理思路
    之前部署了Mysql主从复制环境(MySQL主从复制环境部署【http://blog.itpub.net/31015730/viewspace-2153251/】)以及总结了mysql主从复制的原理和...
    99+
    2024-04-02
  • Android 黑屏问题分析处理总结
    介绍 黑屏问题是显示相关的综合性问题,涉及Android应用层、框架层和底层SurfaceFlinger、屏显等多个领域。下面有一些基础的判断来定位黑屏问题的归属: (1) 屏幕没有亮屏、背光为0则需先从power、屏显角度分析 (2) 屏...
    99+
    2023-08-16
    android
  • Oracle数据不同步的问题分析和解决思路
    其实帮助很多的朋友解决过Oracle数据库数据不同步的问题,看似简单的问题分析出来的原因也是五花八门。比如: Oracle数据库问题的一点总结 在查看一些没有专业DBA维护的数据库的时...
    99+
    2024-04-02
  • ajax数据处理的示例分析
    这篇文章将为大家详细讲解有关ajax数据处理的示例分析,小编觉得挺实用的,因此分享给大家做个参考,希望大家阅读完这篇文章后可以有所收获。需要注意的是,调用的封装的数据库,和jQuery的保存地址一、注册(1...
    99+
    2024-04-02
  • Redis数据库分布式的示例分析
    这篇文章给大家分享的是有关Redis数据库分布式的示例分析的内容。小编觉得挺实用的,因此分享给大家做个参考,一起跟随小编过来看看吧。问题:1-2亿数据需要缓存,如何设计?1 哈希取余分区2亿条记录就是2亿个k,v,假设有3台机器构成一个集群...
    99+
    2023-06-28
  • MYSQL数据交互原理与性能问题分析
    我们在性能测试监控MYSQL数据库时,作为专业非功能性测试人员,我们需要了解操作系统工作原理、业务实现架构逻辑、应用架构实现逻辑、数据库工作原理,才能真正的做好非功能性测试,而大部分业务型交易问题都是因为数...
    99+
    2024-04-02
  • python数据处理实例分析
    今天小编给大家分享一下python数据处理实例分析的相关知识点,内容详细,逻辑清晰,相信大部分人都还太了解这方面的知识,所以分享这篇文章给大家参考一下,希望大家阅读完这篇文章后有所收获,下面我们一起来了解一下吧。一,前言我们现在拿到了一个十...
    99+
    2023-06-30
  • Teradata支持分布式数据处理吗
    是的,Teradata支持分布式数据处理。Teradata的数据库系统是一个高性能的分布式数据库系统,可以处理大规模的数据并进行并行...
    99+
    2024-04-09
    Teradata
  • Python函数加速数据分析处理速度的示例分析
    Python函数加速数据分析处理速度的示例分析,很多新手对此不是很清楚,为了帮助大家解决这个难题,下面小编将为大家详细讲解,有这方面需求的人可以来学习下,希望你能有所收获。前言:Pandas 是 Python 中最广泛使用的数据分析和操作库...
    99+
    2023-06-22
  • 怎么处理ORACLE悬疑分布式事务问题
    这篇文章主要讲解了“怎么处理ORACLE悬疑分布式事务问题”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“怎么处理ORACLE悬疑分布式事务问题”吧!当需要在...
    99+
    2024-04-02
  • 大数据分析之 Python:如何使用 NumPy 解决数据处理中的瓶颈问题?
    在现代社会中,数据的产生量越来越大,数据的处理和分析也变得越来越复杂。在大数据分析过程中,数据处理是一个必不可少的环节。Python 作为一种高效的数据处理语言,能够帮助我们更好地处理数据,NumPy 作为 Python 中的一个重要库,...
    99+
    2023-10-03
    大数据 numpy unix
  • oracle数据库CPU过高问题分析
    这篇文章主要讲解了“oracle数据库CPU过高问题分析”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“oracle数据库CPU过高问题分析”吧!一、执行一条...
    99+
    2024-04-02
  • Couchbase怎么处理数据分片和负载均衡
    Couchbase处理数据分片和负载均衡的方式是通过自动分片和数据分布来实现。具体来说,Couchbase使用一种分布式架构,将数据...
    99+
    2024-03-08
    Couchbase
  • VB.NET处理数据行的示例分析
    VB.NET处理数据行的示例分析,很多新手对此不是很清楚,为了帮助大家解决这个难题,下面小编将为大家详细讲解,有这方面需求的人可以来学习下,希望你能有所收获。对于编程人员来说,运用VB.NET能给他们带来好处是不言而喻的。那么它的哪些优点能...
    99+
    2023-06-17
  • SpringCloudGateway拦截响应问题分析(数据截断问题)
    Spring Cloud Gateway是Spring 官方基于Spring 5.0、Spring Boot 2.0和Project Reactor等技术开发的网关,Spring C...
    99+
    2023-01-07
    Spring Cloud Gateway 拦截响应 Spring Cloud 数据截断 Spring Cloud Gateway 拦截
软考高级职称资格查询
编程网,编程工程师的家园,是目前国内优秀的开源技术社区之一,形成了由开源软件库、代码分享、资讯、协作翻译、讨论区和博客等几大频道内容,为IT开发者提供了一个发现、使用、并交流开源技术的平台。
  • 官方手机版

  • 微信公众号

  • 商务合作