Question

mysql建视图的时候不能用子查询，mysql我用的是5.5版的了，怎么办？

Answer 1

mysql试图中是不可以使用子查询的，你可以把子查询 建立成一个试图，代码如下：

CREATE  VIEW  View_bb  as ；

select id from bb；

然后再建立上面试图，调用该试图代码：

select a.* from aa a inner join  View_bb   b on a.id=b.id，这们就可以用子查询了。

MySQL 是一个关系型数据库，由瑞典 MySQL AB 公司开发，目前属于 Oracle 旗下公司。MySQL 最流行的关系型数据库管理系统，在 WEB 应用方面 MySQL 是最好的 RDBMS (Relational Database Management System，关系数据库管理系统) 应用软件之一。

MySQL 是一种关联数据库管理系统，关联数据库将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度并提高了灵活性。MySQL 所使用的 SQL 语言是用于访问数据库的最常用标准化语言。

MySQL 软件采用了双授权政策(本词条"授权政策")，它分为社区版和商业版，由于其体积小、速度快、总体拥有成本低，尤其是开放源码这一特点，一般中小型网站的开发都选择 MySQL 作为网站数据库。

由于其社区版的性能卓越，搭配 PHP ,Linux和 Apache 可组成良好的开发环境，经过多年的web技术发展,在业内被广泛使用的一种web服务器解决方案之一,称之为LAMP。

Answer 2

mysql试图中是不可以使用子查询的，你可以把子查询 建立成一个试图嘛，
如：
CREATE  VIEW  View_bb  as
select id from bb;

然后再 建立上面试图中  调用该试图，如：
select a.* from aa a inner join  View_bb   b on a.id=b.id

MySql创建视图

(1).第一类：create view v as select * from table;

(2).第二类：create view v as select id,name,age from table;

(3).第三类：create view v[vid,vname,vage] as select id,name,age from table;

如果涉及到数据量过大，业务逻辑需要跨表查询等等也可建立一个跨表的视图，有三种情况：

一、基于同一数据库

这种情况较为简单，只需简单的一行sql命令，如下：

create view v as (select * from table1) union all (select * from table2);

二、基于不同数据库

这种情况只比上面的sql语句多一个数据库的名字，如下：

create view 数据库1.v as (select * from 数据库1.table1) union all (select * from 数据库2.table2);

或

create view 数据库2.v as (select * from 数据库1.table1) union all (select * from 数据库2.table2);

如果执行第一个sql将在数据库1下建立视图，反之亦然；

三、基于不同服务器

这种情况稍微麻烦一点，需要先建立一个远程表来访问远程服务器的数据表，然后再对这个刚建立的远程表和本地表进行视图，步骤如下：

1、查看MySql是否支持federated引擎

(1).登录Mysql;    

(2).mysql>show engines;

(3).如果显示为no,在配置文件中添加：federated (在my.ini)，重新启动mysql服务。

2、创建远程表

mysql>CREATE TABLE federated_table (

id  INT(20)  NOT NULL AUTO_INCREMENT,  

name  VARCHAR(32) NOT NULL DEFAULT '',  

other  INT(20) NOT NULL DEFAULT '0',   

PRIMARY KEY  (id)

)

ENGINE=FEDERATEDDEFAULT

CHARSET=utf8

CONNECTION='mysql://fed_user@remote_host:9306/federated/test_table';

CONNECTION可以按如下方式进行配置：

(1).CONNECTION='mysql://username:password@hostname:port/database/tablename'

(2).CONNECTION='mysql://username@hostname/database/tablename'

(3).CONNECTION='mysql://username:password@hostname/database/tablename'

3、建立视图

create view 本地数据库.v as (select * from 本地数据库.table1) union all (select * from 远程数据库.test_table)。

参考资料

博客园.博客园[引用时间2018-1-7]

Answer 3

首先要明确一点：mysql中是不能建立子查询的。但是可以将子查询 建立为一个视图。

以下为案例：

CREATE  VIEW  View_bb  as   select id from bb;

然后再建立视图中  调用该视图，如：

select a.* from aa a inner join  View_bb   b on a.id=b.id

视图概述

视图是一个虚拟表，其内容由查询定义。同真实的表一样，视图包含一系列带有名称的列和行数据。但是，视图并不在数据库中以存储的数据值集形式存在。行和列数据来自由定义视图的查询所引用的表，并且在引用视图时动态生成。
对其中所引用的基础表来说，视图的作用类似于筛选。定义视图的筛选可以来自当前或其它数据库的一个或多个表，或者其它视图。通过视图进行查询没有任何限制，通过它们进行数据修改时的限制也很少。
视图是存储在数据库中的查询的SQL 语句，它主要出于两种原因：安全原因， 视图可以隐藏一些数据，如：社会保险基金表，可以用视图只显示姓名，地址，而不显示社会保险号和工资数等，另一原因是可使复杂的查询易于理解和使用。这个视图就像一个“窗口”，从中只能看到你想看的数据列。这意味着你可以在这个视图上使用SELECT *，而你看到的将是你在视图定义里给出的那些数据列。

参考资料

百度搜索.mySql建视图[引用时间2018-1-6]

Answer 4

MySQL 8.0 推出了histogram，也叫柱状图或者直方图。先来解释下什么叫直方图。

关于直方图

我们知道，在DB中，优化器负责将SQL转换为很多个不同的执行计划，完了从中选择一个最优的来实际执行。但是有时候优化器选择的最终计划有可能随着DB环境的变化不是最优的，这就导致了查询性能不是很好。比如，优化器无法准确的知道每张表的实际行数以及参与过滤条件的列有多少个不同的值。那其实有时候有人就说了，索引不是可以解决这个问题吗？是的，不同类型的索引可以解决这个问题，但是你不能每个列都建索引吧？如果一张表有1000个字段，那全字段索引将会拖死对这张表的写入。而此时，直方图就是相对来说，开销较小的方法。

直方图就是在 MySQL 中为某张表的某些字段提供了一种数值分布的统计信息。比如字段NULL的个数，每个不同值出现的百分比、最大值、最小值等等。如果我们用过了 MySQL 的分析型引擎brighthouse，那对这个概念太熟悉了。

MySQL的直方图有两种，等宽直方图和等高直方图。等宽直方图每个桶（bucket）保存一个值以及这个值累积频率；等高直方图每个桶需要保存不同值的个数，上下限以及累计频率等。MySQL会自动分配用哪种类型的直方图，我们无需参与。

MySQL 定义了一张meta表column_statistics 来存储直方图的定义，每行记录对应一个字段的直方图，以json保存。同时，新增了一个参数histogram_generation_max_mem_size来配置建立直方图内存大小。

不过直方图有以下限制：

1. 不支持几何类型以及json。2. 不支持加密表和临时表。3. 不支持列值完全唯一。4. 需要手工的进行键值分布。

那我们来举个简单的例子说明直方图对查询的效果提升。

举例

表相关定义以及行数信息等：

• mysql> show create table t2\G

• *************************** 1. row ***************************

• Table: t2

• Create Table: CREATE TABLE `t2` (

• `id` int(11) NOT NULL AUTO_INCREMENT,

• `rank1` int(11) DEFAULT NULL,

• `rank2` int(11) DEFAULT NULL,

• `rank3` int(11) DEFAULT NULL,

• `log_date` date DEFAULT NULL,

• PRIMARY KEY (`id`),

• KEY `idx_rank1` (`rank1`),

• KEY `idx_log_date` (`log_date`)

• ) ENGINE=InnoDB AUTO_INCREMENT=49140 DEFAULT CHARSET=utf8mb4 \

• COLLATE=utf8mb4_0900_ai_ci STATS_PERSISTENT=1 STATS_AUTO_RECALC=0

• 1 row in set (0.00 sec)

• mysql> select count(*) from t2;

• +----------+

• | count(*) |

• +----------+

• | 30940 |

• +----------+

• 1 row in set (0.00 sec)

• 同时对t2克隆了一张表t3

• mysql> create table t3 like t2;

• Query OK, 0 rows affected (0.13 sec)

• mysql> insert into t3 select * from t2;

• Query OK, 30940 rows affected (1.94 sec)

• Records: 30940 Duplicates: 0 Warnings: 0

• 给表t3列rank1和log_date 添加histogram

• mysql> analyze table t3 update histogram on rank1,log_date;+--------+-----------+----------+-----------------------------------------------------+| Table | Op | Msg_type | Msg_text |+--------+-----------+----------+-----------------------------------------------------+| ytt.t3 | histogram | status | Histogram statistics created for column 'log_date'. || ytt.t3 | histogram | status | Histogram statistics created for column 'rank1'. |+--------+-----------+----------+-----------------------------------------------------+2 rows in set (0.19 sec)

• 
  我们来看看histogram的分布状况

• mysql> select json_pretty(histogram) result from information_schema.column_statistics where table_name = 't3' and column_name = 'log_date'\G*************************** 1. row ***************************result: { "buckets": [ [ "2018-04-17", "2018-04-20", 0.01050420168067227, 4 ], ... , [ "2019-04-14", "2019-04-16", 1.0, 3 ] ], "data-type": "date", "null-values": 0.0, "collation-id": 8, "last-updated": "2019-04-17 03:43:01.910185", "sampling-rate": 1.0, "histogram-type": "equi-height", "number-of-buckets-specified": 100}1 row in set (0.03 sec)

• 
  MySQL自动为这个字段分配了等高直方图，默认为100个桶。SQL A：

• select count(*) from t2/t3 where (rank1 between 1 and 10) and log_date < '2018-09-01';

• 
  SQL A的执行结果：

• mysql> select count(*) from t2/t3 where (rank1 between 1 and 10) and log_date < '2018-09-01';+----------+| count(*) |+----------+| 2269 |+----------+1 row in set (0.01 sec)

• 
  无histogram的执行计划

• mysql> explain format=json select count(*) from t2 where (rank1 between 1 and 10) and log_date < '2018-09-01'\G*************************** 1. row ***************************EXPLAIN: { "query_block": { "select_id": 1, "cost_info": { "query_cost": "2796.11" }, "table": { "table_name": "t2", "access_type": "range", "possible_keys": [ "idx_rank1", "idx_log_date" ], "key": "idx_rank1", "used_key_parts": [ "rank1" ], "key_length": "5", "rows_examined_per_scan": 6213, "rows_produced_per_join": 3106, "filtered": "50.00", "index_condition": "(`ytt`.`t2`.`rank1` between 1 and 10)", "cost_info": { "read_cost": "2485.46", "eval_cost": "310.65", "prefix_cost": "2796.11", "data_read_per_join": "72K" }, "used_columns": [ "rank1", "log_date" ], "attached_condition": "(`ytt`.`t2`.`log_date` < '2018-09-01')" } }}

• 
  有histogram的执行计划

• mysql> explain format=json select count(*) from t3 where (rank1 between 1 and 10) and log_date < '2018-09-01'\G*************************** 1. row ***************************EXPLAIN: { "query_block": { "select_id": 1, "cost_info": { "query_cost": "0.71" }, "table": { "table_name": "t3", "access_type": "range", "possible_keys": [ "idx_rank1", "idx_log_date" ], "key": "idx_log_date", "used_key_parts": [ "log_date" ], "key_length": "4", "rows_examined_per_scan": 1, "rows_produced_per_join": 1, "filtered": "100.00", "index_condition": "(`ytt`.`t3`.`log_date` < '2018-09-01')", "cost_info": { "read_cost": "0.61", "eval_cost": "0.10", "prefix_cost": "0.71", "data_read_per_join": "24" }, "used_columns": [ "rank1", "log_date" ], "attached_condition": "(`ytt`.`t3`.`rank1` between 1 and 10)" } }}1 row in set, 1 warning (0.00 sec)

• 我们看到两个执行计划的对比，有Histogram的执行计划cost比普通的sql快了好多倍。上面文字可以看起来比较晦涩，贴上两张图，看起来就很简单了。我这里举得例子相对简单，有兴趣的朋友可以更深入学习其他复杂些的例子。