mysql 如何对视图的名称重命名?

mysql 如何对视图的名称重命名?,第1张

建立视图语句本身就可以写成create or replace,也就是建立或者重建。所以个人想到的办法就是:删除--再命名重建,或者也可以先建立新的视图-再删除旧的,新旧视图并不冲突。

至于重命名,我能想到的只有rename命令,不过这个能 *** 作视图吗,我表示怀疑,你可以试试(按照 *** 作表的方式试试),不过估计不行。

CREATE [OR REPLACE] [ALGORITHM = {UNDEFINED | MERGE | TEMPTABLE}]

VIEW view_name [(column_list)]

AS select_statement

[WITH [CASCADED | LOCAL] CHECK OPTION]

该语句能创建新的视图,如果给定了OR REPLACE子句,该语句还能替换已有的视图。select_statement是一种SELECT语句,它给出了视图的定义。该语句可从基表或其他视图进行选择。

该语句要求具有针对视图的CREATE VIEW权限,以及针对由SELECT语句选择的每一列上的某些权限。对于在SELECT语句中其他地方使用的列,必须具有SELECT权限。如果还有OR REPLACE子句,必须在视图上具有DROP权限。

视图属于数据库。在默认情况下,将在当前数据库创建新视图。要想在给定数据库中明确创建视图,创建时,应将名称指定为db_name.view_name。

mysql>CREATE VIEW test.v AS SELECT * FROM t

表和视图共享数据库中相同的名称空间,因此,数据库不能包含具有相同名称的表和视图。

视图必须具有唯一的列名,不得有重复,就像基表那样。默认情况下,由SELECT语句检索的列名将用作视图列名。要想为视图列定义明确的名称,可使用可选的column_list子句,列出由逗号隔开的ID。column_list中的名称数目必须等于SELECT语句检索的列数。

SELECT语句检索的列可以是对表列的简单引用。也可以是使用函数、常量值、 *** 作符等的表达式。

对于SELECT语句中不合格的表或视图,将根据默认的数据库进行解释。通过用恰当的数据库名称限定表或视图名,视图能够引用表或其他数据库中的视图。

能够使用多种SELECT语句创建视图。视图能够引用基表或其他视图。它能使用联合、UNION和子查询。SELECT甚至不需引用任何表。在下面的示例中,定义了从另一表选择两列的视图,并给出了根据这些列计算的表达式:

mysql>CREATE TABLE t (qty INT, price INT)

mysql>INSERT INTO t VALUES(3, 50)

mysql>CREATE VIEW v AS SELECT qty, price, qty*price AS value FROM t

mysql>SELECT * FROM v

+------+-------+-------+

| qty | price | value |

+------+-------+-------+

|3 |50 | 150 |

+------+-------+-------+

视图定义服从下述限制:

· SELECT语句不能包含FROM子句中的子查询。

· SELECT语句不能引用系统或用户变量。

· SELECT语句不能引用预处理语句参数。

· 在存储子程序内,定义不能引用子程序参数或局部变量。

· 在定义中引用的表或视图必须存在。但是,创建了视图后,能够舍弃定义引用的表或视图。要想检查视图定义是否存在这类问题,可使用CHECK TABLE语句。

· 在定义中不能引用TEMPORARY表,不能创建TEMPORARY视图。

· 在视图定义中命名的表必须已存在。

· 不能将触发程序与视图关联在一起。

在视图定义中允许使用ORDER BY,但是,如果从特定视图进行了选择,而该视图使用了具有自己ORDER BY的语句,它将被忽略。

对于定义中的其他选项或子句,它们将被增加到引用视图的语句的选项或子句中,但效果未定义。例如,如果在视图定义中包含LIMIT子句,而且从特定视图进行了选择,而该视图使用了具有自己LIMIT子句的语句,那么对使用哪个LIMIT未作定义。相同的原理也适用于其他选项,如跟在SELECT关键字后的ALL、DISTINCT或SQL_SMALL_RESULT,并适用于其他子句,如INTO、FOR UPDATE、LOCK IN SHARE MODE、以及PROCEDURE。

如果创建了视图,并通过更改系统变量更改了查询处理环境,会影响从视图获得的结果:

mysql>CREATE VIEW v AS SELECT CHARSET(CHAR(65)), COLLATION(CHAR(65))

Query OK, 0 rows affected (0.00 sec)

mysql>SET NAMES 'latin1'

Query OK, 0 rows affected (0.00 sec)

mysql>SELECT * FROM v

+-------------------+---------------------+

| CHARSET(CHAR(65)) | COLLATION(CHAR(65)) |

+-------------------+---------------------+

| latin1| latin1_swedish_ci |

+-------------------+---------------------+

1 row in set (0.00 sec)

mysql>SET NAMES 'utf8'

Query OK, 0 rows affected (0.00 sec)

mysql>SELECT * FROM v

+-------------------+---------------------+

| CHARSET(CHAR(65)) | COLLATION(CHAR(65)) |

+-------------------+---------------------+

| utf8 | utf8_general_ci |

+-------------------+---------------------+

1 row in set (0.00 sec)

可选的ALGORITHM子句是对标准SQL的MySQL扩展。ALGORITHM可取三个值:MERGE、TEMPTABLE或UNDEFINED。如果没有ALGORITHM子句,默认算法是UNDEFINED(未定义的)。算法会影响MySQL处理视图的方式。

对于MERGE,会将引用视图的语句的文本与视图定义合并起来,使得视图定义的某一部分取代语句的对应部分。

对于TEMPTABLE,视图的结果将被置于临时表中,然后使用它执行语句。

对于UNDEFINED,MySQL将选择所要使用的算法。如果可能,它倾向于MERGE而不是TEMPTABLE,这是因为MERGE通常更有效,而且如果使用了临时表,视图是不可更新的。

明确选择TEMPTABLE的1个原因在于,创建临时表之后、并在完成语句处理之前,能够释放基表上的锁定。与MERGE算法相比,锁定释放的速度更快,这样,使用视图的其他客户端不会被屏蔽过长时间。

视图算法可以是UNDEFINED,有三种方式:

· 在CREATE VIEW语句中没有ALGORITHM子句。

· CREATE VIEW语句有1个显式ALGORITHM = UNDEFINED子句。

· 为仅能用临时表处理的视图指定ALGORITHM = MERGE。在这种情况下,MySQL将生成告警,并将算法设置为UNDEFINED。

正如前面所介绍的那样,通过将视图定义中的对应部分合并到引用视图的语句中,对MERGE进行处理。在下面的示例中,简要介绍了MERGE的工作方式。在该示例中,假定有1个具有下述定义的视图v_merge:

CREATE ALGORITHM = MERGE VIEW v_merge (vc1, vc2) AS

SELECT c1, c2 FROM t WHERE c3 >100

示例1:假定发出了下述语句:

SELECT * FROM v_merge

MySQL以下述方式处理语句:

· v_merge成为t

· *成为vc1、vc2,与c1、c2对应

· 增加视图WHERE子句

所产生的将执行的语句为:

SELECT c1, c2 FROM t WHERE c3 >100

示例2:假定发出了下述语句:

SELECT * FROM v_merge WHERE vc1 <100

该语句的处理方式与前面介绍的类似,但vc1 <100变为c1 <100,并使用AND连接词将视图的WHERE子句添加到语句的WHERE子句中(增加了圆括号以确保以正确的优先顺序执行子句部分)。所得的将要执行的语句变为:

SELECT c1, c2 FROM t WHERE (c3 >100) AND (c1 <100)

事实上,将要执行的语句是具有下述形式的WHERE子句:

WHERE (select WHERE) AND (view WHERE)

MERGE算法要求视图中的行和基表中的行具有一对一的关系。如果不具有该关系。必须使用临时表取而代之。如果视图包含下述结构中的任何一种,将失去一对一的关系:

· 聚合函数(SUM(), MIN(), MAX(), COUNT()等)。

· DISTINCT

· GROUP BY

· HAVING

· UNION或UNION ALL

· 仅引用文字值(在该情况下,没有基本表)。

某些视图是可更新的。也就是说,可以在诸如UPDATE、DELETE或INSERT等语句中使用它们,以更新基表的内容。对于可更新的视图,在视图中的行和基表中的行之间必须具有一对一的关系。还有一些特定的其他结构,这类结构会使得视图不可更新。更具体地讲,如果视图包含下述结构中的任何一种,那么它就是不可更新的:

· 聚合函数(SUM(), MIN(), MAX(), COUNT()等)。

· DISTINCT

· GROUP BY

· HAVING

· UNION或UNION ALL

· 位于选择列表中的子查询

· Join

· FROM子句中的不可更新视图

· WHERE子句中的子查询,引用FROM子句中的表。

· 仅引用文字值(在该情况下,没有要更新的基本表)。

· ALGORITHM = TEMPTABLE(使用临时表总会使视图成为不可更新的)。

关于可插入性(可用INSERT语句更新),如果它也满足关于视图列的下述额外要求,可更新的视图也是可插入的:

· 不得有重复的视图列名称。

· 视图必须包含没有默认值的基表中的所有列。

· 视图列必须是简单的列引用而不是导出列。导出列不是简单的列引用,而是从表达式导出的。下面给出了一些导出列示例:

·3.14159

·col1 + 3

·UPPER(col2)

·col3 / col4

·(subquery)

混合了简单列引用和导出列的视图是不可插入的,但是,如果仅更新非导出列,视图是可更新的。考虑下述视图:

CREATE VIEW v AS SELECT col1, 1 AS col2 FROM t

该视图是不可插入的,这是因为col2是从表达式导出的。但是,如果更新时不更新col2,它是可更新的。这类更新是允许的:

UPDATE v SET col1 = 0

下述更新是不允许的,原因在于,它试图更新导出列:

UPDATE v SET col2 = 0

在某些情况下,能够更新多表视图,假定它能使用MERGE算法进行处理。为此,视图必须使用内部联合(而不是外部联合或UNION)。此外,仅能更新视图定义中的单个表,因此,SET子句必须仅命名视图中某一表的列。即使从理论上讲也是可更新的,不允许使用UNION ALL的视图,这是因为,在实施中将使用临时表来处理它们。

对于多表可更新视图,如果是将其插入单个表中,INSERT能够工作。不支持DELETE。

对于可更新视图,可给定WITH CHECK OPTION子句来防止插入或更新行,除非作用在行上的select_statement中的WHERE子句为“真”。

在关于可更新视图的WITH CHECK OPTION子句中,当视图是根据另一个视图定义的时,LOCAL和CASCADED关键字决定了检查测试的范围。LOCAL关键字对CHECK OPTION进行了限制,使其仅作用在定义的视图上,CASCADED会对将进行评估的基表进行检查。如果未给定任一关键字,默认值为CASCADED。

被取消的命令MySQL 之前提供了一个 rename database db_old to db_new 的命令来直接对数据库改名,可能由于实现的功能不完备(比如,这条命令可能是一个超大的事务,或者是由于之前的表很多还是 MyISAM 等),后来的版本直接取消了这条命令。更改数据库名大致上有以下几种方案:

一、mysqldump 导入导出要说最简单的方法,就是直接用 mysqldump 工具,在旧库导出再往新库导入(最原始、最慢、最容易想到)的方法:旧库 yttdb_old 导出(包含的对象:表、视图、触发器、事件、存储过程、存储函数)

二、改整库的表名利用 MySQL 更改表名的方法来批量把旧库的所有表依次遍历,改名为新库的表。这种方法比第一种要快很多倍,但是没有第一步 *** 作起来那么顺滑,不能一步到位。比如,要把数据库 yttdb_old 改名为 yttdb_new,如果数据库 yttdb_old 里只有磁盘表,那很简单,直接改名即可。或者写个脚本来批量改,非常简单。但是一般旧库里不只有磁盘表,还包含其他各种对象。这时候可以先考虑把旧库的各种对象导出来,完了在逐一改完表名后导进去。

三、历史方案其实在 MySQL 早期还有一种方法。假设 MySQL 部署好了后,所有的 binlog 都有备份,并且二进制日志格式还是 statement 的话,那就可以简单搭建一台从机,让它慢慢追主机到新的库名,等确切要更改旧库的时候,再直接晋升从机为主机即可。这里只需要从机配置一个参数来把旧库指向为新库:replicate-rewrite-db=yttdb_old->yttdb_new不过这种局限性很大,不具备标准化,不推荐。

总结其实针对 MySQL 本身改库名,大致就这么几种方法:

如果数据量小,推荐第一种;

数据量大,则推荐第二种;

数据量巨大,那就非 MySQL 本身能解决的了。

可通过部署第三方 ETL 工具,通过解析 MySQL 二进制日志或其他的方式来把旧库数据直接读取到新库达到改名的目的等等。


欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/zaji/6098112.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-03-14
下一篇 2023-03-14

发表评论

登录后才能评论

评论列表(0条)

保存