第1章:一般信息 / 1.8. MySQL标准的兼容性 / 1.8.5. MySQL与标准SQL的差别
1.8.5.1. 子查询
1.8.5.2. SELECT INTO TABLE
1.8.5.3. 事务和原子操作
1.8.5.4. 存储程序和触发程序
1.8.5.5. 外键
1.8.5.6. 视图
1.8.5.7. ‘--’作为注释起始标记

我们试图使MySQL服务器遵从ANSI SQL标准和ODBC SQL标准,但在某些情况下MySQL服务器执行的操作有所不同:

·         对于VARCHAR列,存储值时删除了尾部空间。(在MySQL 5.0.3中更正)。请参见A.8节,“MySQL中的已知事宜”

·         在某些情况下,定义表或更改其结构时,将CHAR列转换为VARCHAR列。(在MySQL 5.0.3中更正)。请参见13.1.5.1节,“沉寂的列规格变更”

·         删除表时,不自动取消关于表的权限。必须明确发出REVOKE语句,以撤销针对表的权限。请参见13.5.1.3节,“GRANT和REVOKE语法”

·         CAST()函数不支持对REALBIGINT的抛弃。请参见12.8节,“Cast函数和操作符”

·         标准SQL要求,SELECT语句中的HAVING子句能够引用GROUP BY子句中的列。在MySQL 5.0.2之前,不能完成该功能。

1.8.5.1. 子查询

MySQL 4.1支持子查询和导出表。“子查询”指的是嵌套在另一语句中的SELECT语句。“导出表”(未命名视图)是另一语句的FROM子句中的子查询。请参见13.2.8节,“Subquery语法”

从MySQL 4.1版起,可以使用联合或其他方法重写大多数子查询。关于如何完成该任务的更多信息,请参见13.2.8.11节,“对于较早的MySQL版本,采用联合方法重写子查询”

1.8.5.2. SELECT INTO TABLE

MySQL服务器不支持Sybase SQL扩展: SELECT ... INTO TABLE ....。但MySQL服务器支持标准的SQL语法INSERT INTO ... SELECT ...,它基本上相同。请参见13.2.4.1节,“INSERT ... SELECT语法”

INSERT INTO tbl_temp2 (fld_id)
    SELECT tbl_temp1.fld_order_id
    FROM tbl_temp1 WHERE tbl_temp1.fld_order_id > 100;

作为备选方式,可以使用SELECT INTO OUTFILE ...CREATE TABLE ... SELECT。

从5.0版开始,MySQL支持SELECT ... INTO,以及用户变量。在使用光标和局部变量的存储程序中也可以使用相同的语法。请参见20.2.9.3节,“SELECT ... INTO语句”

1.8.5.3. 事务和原子操作

MySQL服务器(3.23至该系列的最高版本,所有4.0版本,以及更高版本)支持采用InnoDB和BDB事务存储引擎的事务。InnoDB提供了全面的ACID兼容性。请参见第15章:存储引擎和表类型

MySQL服务器中的其他非事务性存储引擎(如MyISAM)遵从不同的数据完整性范例,称之为“原子操作”。按照事务术语,MyISAM表总能高效地工作在AUTOCOMMIT=1模式下。原子操作通常能提供可比较的完整性以及更好的性能。

由于MySQL服务器支持两种范例,因而你能决定是否利用原子操作的速度更好地服务于你的应用程序,或使用事务特性。该选择可按表进行。

正如所阐述的那样,事务性和非事务性表类型之间的权衡主要取决于性能。事务性表对内存和磁盘空间的要求更高,CPU开销也更大。另一方面,多种事务性表类型,如InnoDB,也能提供很多显著特性。MySQL服务器的模块化设计允许同时使用不同的存储引擎,以满足不同的要求,并在所有情形下,提供最佳性能。

但是,即便使用非事务性MyISAM表,你将如何使用MySQL服务器的特性来保持严格的完整性呢?这些特性与事务性表类型相比又如何呢?

1.    如果应用程序采用了特定的编写方式,依赖于在关键情况下能够调用ROLLBACK而不是COMMIT,那么事务性类型更方便。使用事务,还能确保未完成的更新或崩溃的活动不被提交到数据库,能为服务器提供自动回滚的机会,并保存你的数据库。

如果使用非事务性表,MySQL服务器几乎在所有情况下均允许你解决潜在的问题,方式是在更新前进行简单检查,并运行检查数据库一致性的简单脚本,如果出现不一致性,该脚本能自动修复它或给出告警。注意,仅使用MySQL日志或增加额外日志,通常能完美地更正表,同时不会造成数据完整性损失。

2.    在很多情况下,能够对关键的事务更新进行重写,使之成为“原子”类型。一般而言,所有由事务解决的完整性问题均能用LOCK TABLES或原子更新解决,从而确保了服务器不会自动中断,后者是事务性数据库系统的常见问题。

3.    为了安全使用MySQL服务器,无论是否使用事务性表,仅需启用备份和二进制日志功能。这样,你就能解决使用其他事务性数据库系统时遇到的任何问题。无论使用的数据库系统是什么,启用备份总是个好主意。

事务范型有自己的优点和不足之处。很多用户和应用程序开发人员喜欢这类简单性,在出现问题时或必要时,通过代码解决问题。但是,即使你是原子操作范型的新手,或更熟悉事务,也请考虑非事务性表的速度益处,与经过优化调整的最快的事务性表相比,它的速度快3~5倍。

在完整性具有最高重要性的情况下,即使是对非事务性表,MySQL也能提供事务级别的可靠性和安全性。如果使用LOCK TABLES锁定了表,所有更新均将被暂时中止直至完整性检查完成。如果你获得了对某一表的READ LOCAL锁定(与写锁定相对),该表允许在表尾执行并行插入,当其他客户端执行插入操作时,允许执行读操作。新插入的记录不会被有读锁定属性的客户端看到,直至解除了该锁定为止。使用INSERT DELAYED,能够将插入项置于本地队列中,直至锁定解除,不会让客户端等待插入完成。请参见13.2.4.2节,“INSERT DELAYED语法”

从我们赋与其名称的意义上,“原子”绝非不可思议的。它仅意味着,你能确信在每个特性更新运行的同时,其他用户不能干涉它,而且不会出现自动回滚(如果你不小心,对于事务性表,这种情况可能发生)。MySQL服务器还能保证不存在脏读。

下面列出了使用非事务性表的一些技术:

·         对于需要事务的循环,通常能使用LOCK TABLES进行编码,不需要光标来更新正在处理的记录。

·         要想避免使用ROLLBACK,可采取下述策略:

1.    使用LOCK TABLES锁定所有希望访问的表。

2.    执行更新前,测试必须为真的条件。

3.    如果一切正常,执行更新。

4.    使用UNLOCK TABLES解除锁定。

与使用具有回滚可能性的事务性表相比,它通常具有更快的速度,虽然并非始终如此。该解决方案唯一不能处理的情形是,在更新中途杀死了线程。在这种情况下,将释放所有锁定,但某些更新可能尚未执行。

·         也可以使用函数在单一操作中更新记录。采用下述技术,能获得效率很高的应用程序。

o        根据其当前值更改列。

o        仅更新出现实际变化的列。

例如,当我们更新某些客户信息时,仅更新已更改的客户数据,与原始行相比,仅测试已更改的数据或依赖于已更改数据的数据是否未出现变化。对于已更改数据的测试,它是通过UPDATE语句的WHERE子句完成的。如果记录未更新,将向客户端发出消息: “一些你改变的数据已被其他用户更改”。接下来,我们在窗口中给出了旧行和新行,以便用户决定使用哪个版本。

这给出了与列锁定类似的结果,但效果更好,使用相对于其当前值的值,仅更新了某些列。这意味着,典型的UPDATE语句与下面给出的类似:

UPDATE tablename SET pay_back=pay_back+125;
 
UPDATE customer
  SET
    customer_date='current_date',
    address='new address',
    phone='new phone',
    money_owed_to_us=money_owed_to_us-125
  WHERE
    customer_id=id AND address='old address' AND phone='old phone';

它很有效,即使其他客户端更改了pay_backmoney_owed_to_us列中的值,也能使用。

·         在很多情况下,用户希望将LOCK TABLES和/或ROLLBACK用于管理唯一ID。可以在不使用锁定功能或回滚的情况下,使用AUTO_INCREMENT列以及LAST_INSERT_ID() SQL函数或mysql_insert_id() C API函数,更有效地处理之。请参见12.9.3节,“信息函数”。请参见25.2.3.36节,“mysql_insert_id()”

我们通常能使用代码来处理行级锁定方面的需求。在某些情况下,实际上不需要它,InnoDB表支持行级锁定。通过MyISAM表,能够在表中使用标志列,并完成类似下面的操作:

UPDATE tbl_name SET row_flag=1 WHERE id=ID;

如果找到行,而且原始行中的row_flag不是1,对于受影响的行数,MySQL返回1。

你可以认为MySQL将前述查询更改为:

UPDATE tbl_name SET row_flag=1 WHERE id=ID AND row_flag <> 1;

1.8.5.4. 存储程序和触发程序

对于MySQL,在5.0版本中实现了存储程序。请参见第20章:存储程序和函数

从5.0.2版开始,在MySQL中实现了基本的触发器功能,计划在MySQL 5.1中进一步发展它。请参见第21章:触发程序

1.8.5.5. 外键

在MySQL服务器3.23.44和更高版本中,InnoDB存储引擎支持对外键约束的检查功能,这些约束包括CASCADEON DELETEON UPDATE。请参见15.2.6.4节,“FOREIGN KEY约束”

对于InnoDB之外的其他存储引擎,MySQL服务器能够解析CREATE TABLE语句中的FOREIGN KEY语法,但不能使用或保存它。未来将进行扩展,能够将这类信息保存到表规范文件中,以便能被mysqldump和ODBC检索。稍后,还将为MyISAM表实现外键约束。

外键增强为数据库开发人员提供了多项益处:

·         假定关联设计恰当,外键约束使得程序员更难将不一致性引入数据库。

·         数据库服务器具有集中式约束检查功能,因而没有必要在应用程序一侧执行这类检查。这样,就消除了不同应用程序使用不同方式检查约束的可能性。

·         使用级联更新和删除,简化了应用程序代码。

·         设计恰当的外键有助于以文档方式记录表间的关系。

请记住,这些好处是以数据库服务器为执行必要检查而需的额外开销为代价的。服务器额外检查会影响性能,对于某些应用程序,该特性不受欢迎,应尽量避免。(出于该原因,在一些主要的商业应用程序中,在应用程序级别上实施了外键逻辑)。

MySQL允许数据库开发人员选择要使用的方法。如果你不需要外键,并希望避免与强制引用完整性有关的开销,可选择另一种表类型取而代之,如MyISAM。(例如,MyISAM存储引擎为仅执行INSERTSELECT操作的应用程序提供了极快的性能,这是因为插入能和检索同时进行)。请参见7.3.2节,“表锁定事宜”

如果你不打算利用引用完整性检查具备的优点,请记住下述要点:

·         不存在服务器端外键关联检查时,应用程序本身必须处理这类关联事宜。例如,将行按恰当顺序插入表时应谨慎,并应避免产生孤立的子记录。必须能够在多记录插入操作期间更正出现的错误。

·         如果ON DELETE是应用程序所需的唯一引用完整性功能,请注意,从MySQL服务器4.0起,可以使用多表DELETE语句,用单一语句从多个表中删除行。请参见13.2.1节,“DELETE语法”

·         从具有外键的表删除记录时,在缺少ON DELETE的情况下,一种解决方式是为应用程序增加恰当的DELETE语句。实际上,它与使用外键同样快,而且移植性更好。

注意,使用外键在某些情况下会导致问题。

·         外键支持能处理很多引用完整性事宜,但仍需要仔细设计键的关系,以避免循环规则或不正确的级联删除组合。

·         DBA需要创建关联拓扑,这会使从备份中恢复单独表变得困难,该类情形并不罕见。(加载依赖其他表的表时,MySQL允许你临时禁止外键检查,从而降低了该难度)。请参见15.2.6.4节,“FOREIGN KEY约束”。在MySQL 4.1.1以前。重新加载时,mysqldump能够生成自动利用该性能的转储文件。

注意,SQL中的外键用于检查和强制引用完整性,而不是联合表。如果打算用SELECT语句获取多个表的结果,可在表之间执行联合操作:

SELECT * FROM t1, t2 WHERE t1.id = t2.id;

请参见13.2.7.1节,“JOIN语法”。请参见3.6.6节,“使用外键”

ODBC应用程序常使用不带“ON DELETE ...”的FOREIGN KEY语法来生成自动WHERE子句。

1.8.5.6. 视图

在MySQL服务器5.0版中实现了视图功能(包括可更新视图)。在5.0.1和更高版本中,提供了二进制版的视图功能。请参见第22章:视图

View(视图)十分有用,它允许用户像单个表那样访问一组关系(表),而且仅允许对它们的这类访问。视图也能限制对行的访问(特定表的子集)。对于列控制的访问,可使用MySQL服务器中的高级权限系统。请参见5.7节,“MySQL访问权限系统”

在设计视图的过程中,我们的宏伟目标是,在SQL的范围内尽可能与关联数据库系统的“Codd's Rule #6”兼容。“所有理论上可更新的视图,实际上也应是可更新的”。

1.8.5.7. ‘--’作为注释起始标记

一些其他SQL数据库采用“--”作为注释开始标志。MySQL服务器采用“#”作为注释起始字符。对于MySQL服务器,也能使用C风格的注释:/*该处为注释*/。请参见9.5节,“注释语法”

MySQL服务器3.23.3和更高版本支持“--”注释风格,但要求注释后面跟1空格(或控制字符,如新行)。之所以要求使用空格,是为了防止与自动生成SQL查询有关的问题,它采用了类似下面的代码,其中,自动为“!payment!”插入“payment”的值:

UPDATE account SET credit=credit-!payment!

考虑一下,如果“payment”的值为负数如“-1”时会出现什么情况:

UPDATE account SET credit=credit--1

在SQL中“credit--1是合法的表达式,但是,如果--1被解释为注释开始,部分表达式将被舍弃。其结果是,表达式的意义与预期的意义完全不同。

UPDATE account SET credit=credit

该语句不会对值作任何更改!这表明,允许注释以“--”开始会产生严重后果。

采用MySQL服务器3.23.3和更高版本中的这类注释方法,“credit--1”实际上很安全。

另一个安全特性是,mysql命令行客户端将删除所有以“--”开头的行。

仅当使用高于3.23.3的MySQL时,下述信息才有意义:

如果有1个文本文件形式的SQL程序,该文件包含“--”注释,应按下述方式使用replace实用工具,将其转换为使用“#”字符的注释:

shell> replace " --" " #" < text-file-with-funny-comments.sql \
         | mysql db_name

而不是通常的:

shell> mysql db_name < text-file-with-funny-comments.sql

你也可以编辑注释文件,将“--”注释更改为“#”注释:

shell> replace " --" " #" -- text-file-with-funny-comments.sql

使用下述命令将其改回去:

shell> replace " #" " --" -- text-file-with-funny-comments.sql