个人中心
文章发布
退出
作者热门文章
- ubuntu12.04环境下使用kvm ioctl接口实现最简单的虚拟机
- Ubuntu 通过无线网络安装Ubuntu Server启动系统后连接无线网络的方法
- 在Ubuntu上搭建网桥的方法
- ubuntu 虚拟机上网方式及相关配置详解
24
4
CFSDN坚持开源创造价值，我们致力于搭建一个资源共享平台，让每一个IT人在这里找到属于你的精彩世界.
这篇CFSDN的博客文章MySQL在关联复杂情况下所能做出的一些优化由作者收集整理，如果你对这篇文章有兴趣，记得点赞哟.
昨天处理了一则复杂关联SQL的优化，这类SQL的优化往往考虑以下四点:
第一.查询所返回的结果集，通常查询返回的结果集很少，是有信心进行优化的； 。
第二.驱动表的选择至关重要，通过查看执行计划，可以看到优化器选择的驱动表,从执行计划中的rows可以大致反映出问题的所在； 。
第三.理清各表之间的关联关系，注意关联字段上是否有合适的索引； 。
第四.使用straight_join关键词来强制表之间的关联顺序，可以方便我们验证某些猜想； 。
SQL: 执行时间:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
mysql>
select
c.yh_id,
-> c.yh_dm,
-> c.yh_mc,
-> c.mm,
-> c.yh_lx,
-> a.jg_id,
-> a.jg_dm,
-> a.jg_mc,
-> a.jgxz_dm,
-> d.js_dm yh_js
->
from
a, b, c
->
left
join
d
on
d.yh_id = c.yh_id
->
where
a.jg_id = b.jg_id
->
and
b.yh_id = c.yh_id
->
and
a.yx_bj = ‘Y
'
-> and c.sc_bj = ‘N'
->
and
c.yx_bj = ‘Y
'
-> and c.sc_bj = ‘N'
->
and
c.yh_dm =
'006939748XX'
;
1 row
in
set
(0.75 sec)
|
这条SQL查询实际只返回了一行数据，但却执行耗费了750ms，查看执行计划:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
|
mysql> explain
->
select
c.yh_id,
-> c.yh_dm,
-> c.yh_mc,
-> c.mm,
-> c.yh_lx,
-> a.jg_id,
-> a.jg_dm,
-> a.jg_mc,
-> a.jgxz_dm,
-> d.js_dm yh_js
->
from
a, b, c
->
left
join
d
on
d.yh_id = c.yh_id
->
where
a.jg_id = b.jg_id
->
and
b.yh_id = c.yh_id
->
and
a.yx_bj = ‘Y
'
-> and c.sc_bj = ‘N'
->
and
c.yx_bj = ‘Y
'
-> and c.sc_bj = ‘N'
->
and
c.yh_dm =
'006939748XX'
;
+—-+————-+——-+——–+——————+———+———+————–+——-+————-+
| id | select_type |
table
| type | possible_keys |
key
| key_len | ref |
rows
| Extra |
+—-+————-+——-+——–+——————+———+———+————–+——-+————-+
| 1 | SIMPLE | a |
ALL
|
PRIMARY
,INDEX_JG |
NULL
|
NULL
|
NULL
| 52616 | Using
where
|
| 1 | SIMPLE | b | ref |
PRIMARY
|
PRIMARY
| 98 | test.a.JG_ID | 1 | Using
index
|
| 1 | SIMPLE | c | eq_ref |
PRIMARY
|
PRIMARY
| 98 | test.b.YH_ID | 1 | Using
where
|
| 1 | SIMPLE | d |
index
|
NULL
|
PRIMARY
| 196 |
NULL
| 54584 | Using
index
|
+—-+————-+——-+——–+——————+———+———+————–+——-+————-+
|
可以看到执行计划中有两处比较显眼的性能瓶颈:
|
1
2
3
|
| 1 | SIMPLE | a |
ALL
|
PRIMARY
,INDEX_JG |
NULL
|
NULL
|
NULL
| 52616 | Using
where
|
| 1 | SIMPLE | d |
index
|
NULL
|
PRIMARY
| 196 |
NULL
| 54584 | Using
index
|
|
由于d是left join的表，所以驱动表不会选择d表，我们在来看看a,b,c三表的大小:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
mysql>
select
count
(*)
from
c;
+———-+
|
count
(*) |
+———-+
| 53731 |
+———-+
mysql>
select
count
(*)
from
a;
+———-+
|
count
(*) |
+———-+
| 53335 |
+———-+
mysql>
select
count
(*)
from
b;
+———-+
|
count
(*) |
+———-+
| 105809 |
+———-+
|
由于b表的数据量大于其他的两表，同时b表上基本没有查询过滤条件，所以驱动表选择B的可能排除； 。
优化器实际选择了a表作为驱动表，而为什么不是c表作为驱动表？我们来分析一下:
第一阶段：a表作为驱动表 a–>b–>c–>d: (1):a.jg_id=b.jg_id—>(b索引:PRIMARY KEY (`JG_ID`,`YH_ID`) ) 。
(2):b.yh_id=c.yh_id—>(c索引:PRIMARY KEY (`YH_ID`)) 。
(3):c.yh_id=d.yh_id—>(d索引:PRIMARY KEY (`JS_DM`,`YH_ID`)) 由于d表上没有yh_id的索引，索引在d表上添加索引:
|
1
|
alter
table
d
add
index
ind_yh_id(yh_id);
|
执行计划:
|
1
2
3
4
5
6
7
8
|
+—-+————-+——-+——–+——————+———–+———+————–+——-+————-+
| id | select_type |
table
| type | possible_keys |
key
| key_len | ref |
rows
| Extra |
+—-+————-+——-+——–+——————+———–+———+————–+——-+————-+
| 1 | SIMPLE | a |
ALL
|
PRIMARY
,INDEX_JG |
NULL
|
NULL
|
NULL
| 52616 | Using
where
|
| 1 | SIMPLE | b | ref |
PRIMARY
|
PRIMARY
| 98 | test.a.JG_ID | 1 | Using
index
|
| 1 | SIMPLE | c | eq_ref |
PRIMARY
|
PRIMARY
| 98 | test.b.YH_ID | 1 | Using
where
|
| 1 | SIMPLE | d | ref | ind_yh_id | ind_yh_id | 98 | test.b.YH_ID | 272 | Using
index
|
+—-+————-+——-+——–+——————+———–+———+————–+——-+————-+
|
执行时间:
|
1
|
1 row
in
set
(0.77 sec)
|
在d表上添加索引后，d表的扫描行数下降到272行（最开始为：54584 ） 。
|
1
|
| 1 | SIMPLE | d | ref | ind_yh_id | ind_yh_id | 98 | test.b.YH_ID | 272 | Using
index
|
|
第二阶段：c表作为驱动表 。
d ^ | c–>b–>a 由于在c表上有yh_dm过滤性很高的筛选条件，所以我们在yh_dm上创建一个索引:
|
1
2
3
4
5
6
|
mysql>
select
count
(*)
from
c
where
yh_dm =
'006939748XX'
;
+———-+
|
count
(*) |
+———-+
| 2 |
+———-+
|
添加索引:
|
1
|
alter
table
c
add
index
ind_yh_dm(yh_dm)
|
查看执行计划:
|
1
2
3
4
5
6
7
8
|
+—-+————-+——-+——–+——————-+———–+———+————–+——-+————-+
| id | select_type |
table
| type | possible_keys |
key
| key_len | ref |
rows
| Extra |
+—-+————-+——-+——–+——————-+———–+———+————–+——-+————-+
| 1 | SIMPLE | a |
ALL
|
PRIMARY
,INDEX_JG |
NULL
|
NULL
|
NULL
| 52616 | Using
where
|
| 1 | SIMPLE | b | ref |
PRIMARY
|
PRIMARY
| 98 | test.a.JG_ID | 1 | Using
index
|
| 1 | SIMPLE | c | eq_ref |
PRIMARY
,ind_yh_dm |
PRIMARY
| 98 | test.b.YH_ID | 1 | Using
where
|
| 1 | SIMPLE | d | ref | ind_yh_id | ind_yh_id | 98 | test.b.YH_ID | 272 | Using
index
|
+—-+————-+——-+——–+——————-+———–+———+————–+——-+————-+
|
执行时间:
|
1
|
1 row
in
set
(0.74 sec)
|
在c表上添加索引后，索引还是没有走上，执行计划还是以a表作为驱动表，所以我们这里来分析一下为什么还是以a表作为驱动表?
1):c.yh_id=b.yh_id—>( PRIMARY KEY (`JG_ID`,`YH_ID`) ) 。
a.如果以c表为驱动表，则c表与b表在关联的时候，由于在b表没有yh_id字段的索引，由于b表的数据量很大，所以优化器认为这里如果以c表作为驱动表，则会与b表产生较大的关联（这里可以使用straight_join强制使用c表作为驱动表）； b.如果以a表为驱动表，则a表与b表在关联的时候，由于在b表上有jg_id字段的索引，所以优化器认为以a作为驱动表的代价是小于以c作为驱动板的代价； 所以我们如果要以C表为驱动表，只需要在b上添加yh_id的索引:
|
1
|
alter
table
b
add
index
ind_yh_id(yh_id);
|
2):b.jg_id=a.jg_id—>( PRIMARY KEY (`JG_ID`) ) 。
3):c.yh_id=d.yh_id—>( KEY `ind_yh_id` (`YH_ID`) ) 执行计划:
|
1
2
3
4
5
6
7
8
|
+—-+————-+——-+——–+——————-+———–+———+————–+——+————-+
| id | select_type |
table
| type | possible_keys |
key
| key_len | ref |
rows
| Extra |
+—-+————-+——-+——–+——————-+———–+———+————–+——+————-+
| 1 | SIMPLE | c | ref |
PRIMARY
,ind_yh_dm | ind_yh_dm | 57 | const | 2 | Using
where
|
| 1 | SIMPLE | d | ref | ind_yh_id | ind_yh_id | 98 | test.c.YH_ID | 272 | Using
index
|
| 1 | SIMPLE | b | ref |
PRIMARY
,ind_yh_id | ind_yh_id | 98 | test.c.YH_ID | 531 | Using
index
|
| 1 | SIMPLE | a | eq_ref |
PRIMARY
,INDEX_JG |
PRIMARY
| 98 | test.b.JG_ID | 1 | Using
where
|
+—-+————-+——-+——–+——————-+———–+———+————–+——+————-+
|
执行时间:
|
1
|
1 row
in
set
(0.00 sec)
|
可以看到执行计划中的rows已经大大降低，执行时间也由原来的750ms降低到0 ms级别； 。
最后此篇关于MySQL在关联复杂情况下所能做出的一些优化的文章就讲到这里了,如果你想了解更多关于MySQL在关联复杂情况下所能做出的一些优化的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。
24
4
0
目前我正在构建相当大的网络系统，我需要强大的 SQL 数据库解决方案。我选择 Mysql 而不是 Postgres，因为一些任务需要只读(MyISAM 引擎)而其他任务需要大量写入(InnoDB)。
我在 mysql 中使用如下命令。当它显示表格数据时，它被格式化为一个非常干净的表格，间距均匀且 |作为列分隔符。 SELECT * FROM TABLE_NAME; 当我从 CLI 运行命令时，如下
我知道这个问题之前已经被问过好几次了，我已经解决了很多问题，但到目前为止没有任何效果。 MySQL 试图将自身安装到的目录 (usr/local/mysql) 肯定有问题。关于我的错误的奇怪之处在于我
以下是我的 SQL 数据结构，我正在尝试如下两个查询: Select Wrk_ID, Wrk_LastName, Skill_Desc from Worker, Skill where
我们有一个本地 mysql 服务器(不在公共(public)域上)，并希望将该服务器复制到我们拥有的 google 云 sql 实例。我的问题是:1.这可能吗？2.我们的本地服务器只能在本地网络上访问
我有一个表(test_table)，其中一些字段值(例如字段 A、B 和 C)是从外部应用程序插入的，还有一个字段(字段 D)，我想从现有表(store_table)插入其值，但在插入前者(A、B 和
我想创建一个 AWS RDS 实例，然后使用 terraform 管理数据库用户。因此，首先，我创建了一个 RDS 实例，然后使用创建的 RDS 实例初始化 mysql 提供程序，以进一步将其用于用户
当用户在我的网站上注册时，他们会在我的一个数据库中创建自己的表格。该表存储用户发布的所有帖子。我还想做的是也为他们生成自己的 MySql 用户——该用户仅有权从他们的表中读取、写入和删除。 创建它应该
我有一个关于 ColdFusion 和 Mysql 的问题。我有两个表:PRODUCT 和 PRODUCT_CAT。我想列出包含一些标记为:IS_EXTRANET=1 的特殊产品的类别。所以我写了这个
我想获取 recipes_id 列的值，以获取包含 ingredient_id 的 2,17 和 26 条目的值。 假设 ingredient_id 2 丢失则不获取记录。 我已经尝试过 IN 运算符
在 Ubuntu 中，我通常安装两者，但 MySQL 的客户端和服务器之间有什么区别。 作为奖励，当一个新语句提到它需要 MySQL 5.x 时，它是指客户端、服务器还是两者兼而有之。例如这个链接ht
我重新访问了我的数据库并注意到我有一些 INT 类型的主键。 这还不够独特，所以我想我会有一个指导。 我来自微软 sql 背景，在 ssms 中你可以 选择类型为“uniqeidentifier”并自
我的系统上有 MySQL，我正在尝试确定它是 Oracle MySQL 还是 MySQL。 Oracle MySQL 有区别吗: http://www.oracle.com/us/products/m
我是在生产 MySQL 中运行的应用程序的新维护者。之前的维护者已经离开，留下的文档很少，而且联系不上了。 我面临的问题是执行以下请求大约需要 10 秒: SELECT COUNT(*) FROM `
我有两个位于不同机器上的 MySQL 数据库。我想自动将数据从一台服务器传输到另一台服务器。比方说，我希望每天早上 4:00 进行数据传输。 可以吗？是否有任何 MySQL 内置功能可以让我们做到这一
有什么方法可以使用 jdbc 查询位于 mysql 根目录之外的目录中的 mysql 表，还是必须将它们移动到 mysql 根目录内的数据库文件夹中？我在 Google 上搜索时没有找到任何东西。 最
我在 mysql 数据库中有两个表。成员和 ClassNumbers。两个表都有一个付费年份字段，都有一个代码字段。我想用代码数字表中的值更新成员表中的付费年份，其中成员中的代码与 ClassNumb
情况:我有 2 台服务器，其中一台当前托管一个实时 WordPress 站点，我希望能够将该站点转移到另一台服务器，以防第一台服务器出现故障。传输源文件很容易；传输数据库是我需要弄清楚如何做的。两台服
Phpmyadmin 有一个功能是“复制数据库到”..有没有mysql查询来写这个函数？类似于将 db A 复制到新的 db B。 最佳答案 首先创建复制数据库: CREATE DATABASE du
我有一个使用 mySQL 作为后端的库存软件。我已经在我的计算机上对其进行了测试，并且运行良好。 当我在计算机上安装我的软件时，我必须执行以下步骤: 安装 mySQL 服务器 将用户名指定为“root
我是一名优秀的程序员,十分优秀！