子查询及连接 - 版本历史

Eijux：/* 连接查询和子查询的效率 */

2021-05-07T15:25:25Z

连接查询和子查询的效率

←上一版本		2021年5月7日 (五) 23:25的版本
第225行：		第225行：
	所以当我们看到“selectType”是“dependent subquery”（相关子查询）的时候不要以为这就是最坏的方式，有可能这就是最好的查询方式（比如外查询的结果集很小，内查询能使用索引）。		所以当我们看到“selectType”是“dependent subquery”（相关子查询）的时候不要以为这就是最坏的方式，有可能这就是最好的查询方式（比如外查询的结果集很小，内查询能使用索引）。

	== ~~连接查询和子查询的效率~~ ==		== 子查询和连接查询的效率 ==
	一般都推荐使用“连接查询”来替代“子查询”：		一般都推荐使用“连接查询”来替代“子查询”：
	# “子查询”：		# “子查询”：

Eijux：/* 连接查询和子查询的效率 */

2021-05-07T15:25:03Z

连接查询和子查询的效率

←上一版本		2021年5月7日 (五) 23:25的版本
第228行：		第228行：
	一般都推荐使用“连接查询”来替代“子查询”：		一般都推荐使用“连接查询”来替代“子查询”：
	# “子查询”：		# “子查询”：
	#* ~~不需要表间有字段关联，所以更灵活；~~		#* 不需要表间有字段关联，所以更灵活；（所以“连接查询”都能替换为“子查询”，但“子查询”不一定能替换为“连接查询”）
	~~#*:（所以“连接查询”都能替换为“子查询”，但“子查询”不一定能替换为“连接查询”）~~
	#* '''多次遍历数据'''（笛卡尔集），性能更低；		#* '''多次遍历数据'''（笛卡尔集），性能更低；
	# “连接查询”：		# “连接查询”：

Eijux：/* 连接查询和子查询的效率 */

2021-05-07T15:24:36Z

连接查询和子查询的效率

←上一版本		2021年5月7日 (五) 23:24的版本
第226行：		第226行：

	== 连接查询和子查询的效率 ==		== 连接查询和子查询的效率 ==
			一般都推荐使用“连接查询”来替代“子查询”：
			# “子查询”：
			#* 不需要表间有字段关联，所以更灵活；
			#*:（所以“连接查询”都能替换为“子查询”，但“子查询”不一定能替换为“连接查询”）
			#* '''多次遍历数据'''（笛卡尔集），性能更低；
			# “连接查询”：
			#* 表间必须要有字段关联；
			#* 一般连接遍历较少，且采用“'''嵌套循环连接'''”算法（“NLJ”或“BNL”）减少了内表读取次数，性能更高；

			所以对于少数据量时使用“子查询”更为灵活，而大数据量时“连接查询”则更为高效。

			而 MySQL 对于子查询也有一些自动优化方式，其中之一就是“半联接”。

Eijux：/* “in”与“exists” */

2021-05-07T14:53:35Z

“in”与“exists”

←上一版本		2021年5月7日 (五) 22:53的版本
第67行：		第67行：

	'''“in”与“exists”的效率：'''<br/>		'''“in”与“exists”的效率：'''<br/>
			* MySQL 会对“in”子查询进行优化，其中之一就是使用“EXISTS策略”。

	MySQL 中二者区别在于：		MySQL 中二者区别在于：
	* “in”语句是把外表和内表作 hash 连接（本质是'''基于内表查询结果集作loop循环'''）；		* “in”语句是把外表和内表作 hash 连接（本质是'''基于内表查询结果集作loop循环'''）；

Eijux：/* “嵌套循环关联”算法 */

2021-05-07T14:03:05Z

“嵌套循环关联”算法

←上一版本		2021年5月7日 (五) 22:03的版本
第151行：		第151行：

	=== “嵌套循环关联”算法 ===		=== “嵌套循环关联”算法 ===
	* 见：“[[MySQL 优化：优化 SQL 语句：优化 SELECT 语句]]”中“嵌套循环连接算法”一节		* 见：“'''[[MySQL 优化：优化 SQL 语句：优化 SELECT 语句]]'''”中“嵌套循环连接算法”一节
	* MySQL 中“关联（join）”一词包含的意义比一般意义上理解的要更广泛。总的来说，MySQL 认为任何一个查询都是一次“关联”，而并不仅仅是一个查询需要到两个表的匹配才叫关联，所以在MySQL中，每一个查询，每一个片段（包括子查询，设置基于表单的select）都可能是关联。		* MySQL 中“关联（join）”一词包含的意义比一般意义上理解的要更广泛。总的来说，MySQL 认为任何一个查询都是一次“关联”，而并不仅仅是一个查询需要到两个表的匹配才叫关联，所以在MySQL中，每一个查询，每一个片段（包括子查询，设置基于表单的select）都可能是关联。

Eijux：/* MySQL对“子查询”的自动优化 */

2021-05-07T14:02:49Z

MySQL对“子查询”的自动优化

←上一版本		2021年5月7日 (五) 22:02的版本
第36行：		第36行：
	=== MySQL对“子查询”的自动优化 ===		=== MySQL对“子查询”的自动优化 ===
	* 见：“'''[[MySQL 优化：优化 SQL 语句：优化子查询，派生表和视图引用]]'''”		* 见：“'''[[MySQL 优化：优化 SQL 语句：优化子查询，派生表和视图引用]]'''”


	MySQL 可以通过以下方式来优化子查询：【“半联接”、“实体化”、“EXISTS策略”、“合并”】		MySQL 可以通过以下方式来优化子查询：【“半联接”、“实体化”、“EXISTS策略”、“合并”】

Eijux：/* MySQL对“子查询”的自动优化 */

2021-05-07T14:02:35Z

MySQL对“子查询”的自动优化

←上一版本		2021年5月7日 (五) 22:02的版本
第35行：		第35行：

	=== MySQL对“子查询”的自动优化 ===		=== MySQL对“子查询”的自动优化 ===
			* 见：“'''[[MySQL 优化：优化 SQL 语句：优化子查询，派生表和视图引用]]'''”


	MySQL 可以通过以下方式来优化子查询：【“半联接”、“实体化”、“EXISTS策略”、“合并”】		MySQL 可以通过以下方式来优化子查询：【“半联接”、“实体化”、“EXISTS策略”、“合并”】
	# 对于“IN”（或“=ANY”）子查询，优化器具有以下选择：		# 对于“IN”（或“=ANY”）子查询，优化器具有以下选择：
第46行：		第49行：
	#* 将派生表合并到外部查询块中		#* 将派生表合并到外部查询块中
	#* 将派生表实体化为内部临时表		#* 将派生表实体化为内部临时表

	~~见：“[[MySQL 优化：优化 SQL 语句：优化子查询，派生表和视图引用]]”~~

	=== “in”与“exists” ===		=== “in”与“exists” ===

Eijux：/* “in”子查询 */

2021-05-07T14:00:50Z

“in”子查询

←上一版本		2021年5月7日 (五) 22:00的版本
第49行：		第49行：
	见：“[[MySQL 优化：优化 SQL 语句：优化子查询，派生表和视图引用]]”		见：“[[MySQL 优化：优化 SQL 语句：优化子查询，派生表和视图引用]]”

	=== ~~“in”子查询~~ ===		=== “in”与“exists” ===
			“in”子查询：
	# in( 常量列表 )：		# in( 常量列表 )：
	#: 相当于多个or条件的叠加。		#: 相当于多个or条件的叠加。
第60行：		第61行：
	#: 这种情况一般是作为 where 语句后面的一个条件。		#: 这种情况一般是作为 where 语句后面的一个条件。
	#: MySQL 5.6.5 之后可以将 where 之后的 select 物化（'''实体化'''）的情况。在这种情况下mysql会在内存中创建一个'''临时表'''，然后使用in（常量列表）的形式进行查询。		#: MySQL 5.6.5 之后可以将 where 之后的 select 物化（'''实体化'''）的情况。在这种情况下mysql会在内存中创建一个'''临时表'''，然后使用in（常量列表）的形式进行查询。
			* 注意：“in”不是进行的索引范围扫描，而是进行单独的等值查询。

			“exists”子查询：对外表进行循环查询，再根据exists条件语句过滤符合的数据。


	* ~~注意：“in”不是进行的索引范围扫描，而是进行单独的等值查询。~~		'''“in”与“exists”的效率：'''<br/>
			MySQL 中二者区别在于：
			* “in”语句是把外表和内表作 hash 连接（本质是'''基于内表查询结果集作loop循环'''）；
			**【所以内表是否使用索引对“in( select子查询 )”查询影响更大】
			* 而“exists”语句是'''对外表作loop循环'''，每次loop循环再对内表进行查询。
			**【所以外查询是否使用索引对“exists”影响更大】
			所以，一直认为的“exists”比“in”语句的效率要高，并不准确的。而是要区分环境的:
			# 如果查询的两个表大小相当，那么用“in”与“exists”差别不大。
			# 如果两个表大小悬殊，则'''子查询表大的用“exists”，子查询表小的用“in”'''。【可能受不同版本的优化的影响而不一】

	~~“exists”子查询：对外表进行循环查询，并且根据exists条件语句过滤符合的数据。~~		* 而对于“not in”（反向范围不使用索引）与“not exists”，由其执行过程可知“not exists”效率更高。

	== 连接 ==		== 连接 ==

Eijux：/* “exists”子查询 */

2021-05-07T13:41:56Z

“exists”子查询

←上一版本		2021年5月7日 (五) 21:41的版本
第63行：		第63行：
	* 注意：“in”不是进行的索引范围扫描，而是进行单独的等值查询。		* 注意：“in”不是进行的索引范围扫描，而是进行单独的等值查询。

	~~=== “exists”子查询 ===~~		“exists”子查询：对外表进行循环查询，并且根据exists条件语句过滤符合的数据。





	== 连接 ==		== 连接 ==

Eijux：/* “in”子查询 */

2021-05-07T13:36:02Z

“in”子查询

←上一版本		2021年5月7日 (五) 21:36的版本
第50行：		第50行：

	=== “in”子查询 ===		=== “in”子查询 ===
			# in( 常量列表 )：
			#: 相当于多个or条件的叠加。
			#: <syntaxhighlight lang="mysql" highlight="">
			select * from user where userId in (1, 2, 3);
			-- 等效于
			select * from user where userId = 1 or userId = 2 or userId = 3;
			</syntaxhighlight>
			# in( select子查询 )：
			#: 这种情况一般是作为 where 语句后面的一个条件。
			#: MySQL 5.6.5 之后可以将 where 之后的 select 物化（'''实体化'''）的情况。在这种情况下mysql会在内存中创建一个'''临时表'''，然后使用in（常量列表）的形式进行查询。

			* 注意：“in”不是进行的索引范围扫描，而是进行单独的等值查询。



	=== “exists”子查询 ===		=== “exists”子查询 ===

子查询及连接 - 版本历史

Eijux：​/* 连接查询和子查询的效率 */

Eijux：​/* 连接查询和子查询的效率 */

Eijux：​/* 连接查询和子查询的效率 */

Eijux：​/* “in”与“exists” */

Eijux：​/* “嵌套循环关联”算法 */

Eijux：​/* MySQL对“子查询”的自动优化 */

Eijux：​/* MySQL对“子查询”的自动优化 */

Eijux：​/* “in”子查询 */

Eijux：​/* “exists”子查询 */

Eijux：​/* “in”子查询 */

Eijux：/* 连接查询和子查询的效率 */

Eijux：/* 连接查询和子查询的效率 */

Eijux：/* 连接查询和子查询的效率 */

Eijux：/* “in”与“exists” */

Eijux：/* “嵌套循环关联”算法 */

Eijux：/* MySQL对“子查询”的自动优化 */

Eijux：/* MySQL对“子查询”的自动优化 */

Eijux：/* “in”子查询 */

Eijux：/* “exists”子查询 */

Eijux：/* “in”子查询 */