当前位置:七道奇文章资讯数据防范MySQL防范
日期:2011-05-02 15:44:00  来源:本站整理

MySQL数据库技术(19)[MySQL防范]

赞助商链接



  本文“MySQL数据库技术(19)[MySQL防范]”是由七道奇为您精心收集,来源于网络转载,文章版权归文章作者所有,本站不对其观点以及内容做任何评价,请读者自行判断,以下是其具体内容:

3.9 MySQL 不支持的功效
? ? 本节介绍其他数据库中有而MySQL 中无的功效.它介绍省略了什么功效,以及在需求这些功效时怎么办.普通情形下, MySQL 之所以忽视某些功效是因为它们有负面性能影响.有的功效正在开辟者的筹划清单上,一旦找到一种办法可以实现呼应的功效而又不致于影响
杰出性能的目标,就会对它们举行实现.
? ? ■ 子挑选.子挑选是嵌套在另一个SELECT 语句内的SELECT 语句,以下面的查询所示:
? ? SELECT * FROM score
? ? WHERE event_id IN (SELECT event_id FROM event WHERE type = "T")
? ? 子挑选打算在MySQL 3.24 中给出,到当时它们就不会忽视了.但到当时,很多用子挑选撰写的查询也可以用衔接来编写.请参阅3 . 8 . 1节"将子挑选编写为衔接".
? ? ■ 事件处理和提交/回退.事件处理是由其他客户机作为一个整体不中止履行的一组S Q L语句.提交/回退功效答应规定数条语句作为一个整体履行或不履行.即,假如事件处理中的任何一条语句失利,那么直到该语句前履行的全部语句的作用都被撤消.
ySQL 自动举行单一SQL 语句的同步免得客户机彼此干扰.(比方,两个客户机不能对相同的表举行同时写入.)此外,可操纵LOCK TABLES 和UNLOCK TA B L ES将数条语句构成一个整体,这使您可以完成单条语句的并发掌握所不能满意的操作.MySQL 与事件处理有关的问题是,它不能自动对数条语句举行组织,并且假如这些语句中有某一条失利后也不能对它们举行回退.
? ? 为了弄清事件处理为什么有效,可举例阐明.假定您在服装贩卖业工作,无论什么时刻,只要您的贩卖人员举行了一次贩卖,都要更新库存数目.下面的例子阐明了在多个贩卖人员同时更新数据库时大概呈现的问题(假定初始的衬衫库存数目为4 7):
? ? t1 贩卖人员1卖出3件衬衫
? ? t2 贩卖人员检索当前衬衫计数( 4 7):
? ? SELECT quantity FROM inventory WHERE item = "shirt"
? ? t3 贩卖人员2卖出2件衬衫
? ? t4 贩卖人员2检索当前衬衫计数( 4 7)
? ? SELECT quantity FROM inventory WHERE item = "shirt"
? ? t5 贩卖人员1计算库存的新数目为47 - 3 = 44 并设置衬衫计数为44:
? ? UPDATE inventory SET quantity = 44 WHERE item = "shirt"
? ? t6 贩卖人员2计算库存的新数目为47 - 2 = 45 并设置衬衫计数为45:
? ? UPDATE inventory SET quantity = 45 WHERE item = "shirt"
? ? 在这个事件序列完毕时,您已经卖掉了5 件衬衫,但库存数目倒是45 而不是4 2.问题是假如在一条语句中查看库存而在另一条语句中更新其值,这是一个多语句的事件处理.第二条语句中所举行的活动取决于第一条语句中检索出的值.但是假如在重叠的时间范围内呈现独立的事件处理,则每个事件处理的语句会胶葛在一同,并且彼此干扰.在事件处理型的数据库中,每个贩卖人员的语句可作为一个事件处理履行,这样,贩卖人员2 的语句在贩卖人员1 的语句完成之前不会被履行.在MySQL 中,可用两种办法到达这个目的:
? ? ■ 办法1:作为一个整体履行一组语句.可操纵LOCK TABLES 和UNLOCK TABLES将语句组织在一同,并将它们作为一个原子单元履行:锁居处需利用的表,公布查询,然后释放这些锁.这样禁止了其他人在您锁住这些表时利用它们.操纵表同步,库存情形以下所示:
? ? t1 贩卖人员1卖出3件衬衫
? ? t2 贩卖人员1恳求一个锁并检索当前衬衫计数(47)
? ? LOCK TABLES inventory WRITE
? ? SELECT quantity FROM inventory WHERE item = "shirt"
? ? t3 贩卖人员2卖出2件衬衫
? ? t4 贩卖人员2试图获得一个锁:这被阻塞,因为贩卖人员1 已经占住了锁:
? ? LOCK TABLES inventory WRITE
? ? t5 贩卖人员1计算库存的新数目为47 - 3 = 44 并设置衬衫计数为44,然后释放锁:
? ? UPDATE inventory SET quantity = 44 WHERE item = "shirt"
? ? UNLOCK TABLES
? ? t6 目前贩卖人员2的锁恳求成功.贩卖人员2检索当前衬衫计数( 44)
? ? SELECT quantity FROM inventory WHERE item = "shirt"
? ? t7 贩卖人员2计算库存的新数目为44 - 2 = 42,设置衬衫计数为4 2,然后释放锁:
? ? UPDATE inventory SET quantity = 42 WHERE item = "shirt"
? ? UNLOCK TABLES
? ? 目前来自两个事件处理的语句不混合了,并且库存衬衫数也精确举行了设置.我们在这里利用了一个WRITE 锁,因为我们需求改正inventory 表.假如只是读取表,可以利用READ 锁.当您正在利用表时,这个锁答应其他客户机读取表.在方才举的例子中,贩卖人员2大约不会注意到履行速度上的差别,因为此中的事件处理都很短,履行速度很快.但是,作为一个具有广泛意义的法则,那就是应当尽大概避免长时间地锁住表.
? ? 假如您正在利用多个表,那么在您履行成组查询之前,必须锁住他们.假如只是从某个特定的表中读取数据,那么只需给该表加一个读出锁而不是写入锁.假定有一组查询,此中想对inventory 表作某些更改,而同时需求从customer 表中读取某些数据.在此情形下,inventory 表上需求一个写入锁,而customer 表上需求一个读出锁:
? ? LOCK TABLES inventory WRITE,customer READ
? ? ...
? ? UNLOCK TABLES
? ? 这里要求您自己对表举行加锁和解锁.支持事件处理的数据库系统将会自动完成这些工作.但是,在作为一个整体履行的分组语句方面,无论在能否支持事件处理的数据库中都是相同的.
? ? ■ 办法2:利用相对更新而不是绝对更新.要办理来自多个事件处理的语句混合问题,应消除语句之间的依靠性.固然这样做并不都老是大概的,它只针对我们的库存例子可行.关于办法1中所用的库存更新办法,此中事件处理需求查看当前库存数目,并根据贩卖衬衫的数目计算新值,然后更新衬衫的数目.有大概通过相关于当前衬衫数目举行计数更新,在一个步骤中完成工作.以下所示:
? ? t1 贩卖人员1卖出3件衬衫
? ? t2 贩卖人员1将衬衫计数减3:
? ? UPDATE inventory SET quantity = quantity - 3 WHERE item = "shirt"
? ? t3 贩卖人员2卖出2件衬衫
? ? t4 贩卖人员2将衬衫计数减2:
? ? UPDATE inventory SET quantity = quantity - 2 WHERE item = "shirt"
? ? 因此,这里根本不需求多条语句的事件处理,从而也不需求锁住表以模拟事件处理功效.假如所利用的事件处理范例与这里近似,那么便可以不用事件处理也能完成工作.上面的例子阐明了在特别情形下怎样避免对事件处理功效的需求.但这并非说不存在那种确切需求事件处理功效的场所.典型的例子是财政转账,此中钱从一个账户转到另一个账户.假定Bill 给Bob 开了一张$100 的支票,Bob 兑现了这张支票.Bill 的户头上应当减掉$100 而Bob 的户头上应当增添相同数目的钱:
? ? UPDATE account SET balance = balance -100 WHERE name = "Bill"
? ? UPDATE account SET balance = balance +100 WHERE name = "Bob"
? ? 假如在这两条语句履行中,系统发生了崩溃,此事件处理就不完好了.具有真正事件处理和提交/回退功效的数据库系统可以处理这种情形(至少从理论上可以处理.您大概仍旧必须判断碰到了哪些事件处理并重新公布它们,但至少不会耽忧事件只处理了一半).在MySQL 中,系统崩溃时可通过查抄更新日记来判断事件处理的状况,固然这大概需求对日记举行某种手工查抄.
? ? ■ 外部键和引用完好性.外部键答应定义一个表中的键与另一个表中的键相关,而引用完好性答应安排对包含外部键的表可以做什么的约束.比方, samp_db 样例数据库的score 表中包含一个student_id 列,我们用它来将学分记录关联到student 表中的学生.score.student_id 将定义为支持此概念的数据库中的一个外部键,我们将在其上加上一条约束,使不能为student 表中不存在的学生输入学分记录.此外,应当答应级联删除,以便假如某个学生从student 表中被删除后,该学生的任何学分记录将会自动地从
score 表中删除.
? ? 外部键有助于保持数据的一致性,并且还供应了某种便利的手段.MySQL 不支持外部键的缘由主如果由于它对数据库的实现与保护有负作用.(MySQL 参考指南具体列出了这些缘由.)注意,关于外部键的这种见解与其他数据库文献中的见解有些差别,有的数据库文献普通将它们描写成"基本的".MySQL 的开辟者并不赞成这个概念.假如您赞成,那么最好是考虑采取其他供应外部键支持的数据库.假如数据具有分外复杂的关系,您大概不但愿担负在利用程序中实现这些相关性的工作.(即便这样做的工作量要比增添几个额外的DELETE 语句的工作量要稍少一些.)除了在一定程度上可以在CREATE TABLE 语句中解析FOREIGN KEY 子句外,MySQL 不支持外部键.(这有助于使从其他数据库移植代码到MySQL 更为简单.)MySQL 不强迫让外部键作为一种约束,也不供应级联删除功效.
? ? 外部键强迫实施的约束普通不难用程序逻辑来实现.有时,它只是一个怎样举行数据录入处理的问题.比方,为了将一个新记录插入score 表,不太大概插入不存在的学生的学分.明显,输入一组学分的办法应当是按照从student 表得出的学生名单,对每个学生,取其学分并操纵该学生的ID 号产生一个score 表的记录.关于这个历程,不存在录入一个不存在的学生的记录的大概.您不会凭空造出一个学分记录来插入score 表.要实现DELETE 的级联效果,必须用自己的利用程序逻辑来完成.假定想要删除13 号学生.这也隐含表示需求删除该学生的学分记录.在支持级联删除的数据库中,只需求用以下的语句便可以删除student 表的记录和呼应的score 表的记录:
? ? DELETE FROM student WHERE student_id = 13
? ? 而在MySQL 中,必须明确地用DELETE 语句自己举行第二个删除语句:
? ? DELETE FROM student WHERE student_id = 13
? ? DELETE FROM score WHERE student_id = 13
? ? ■ 存储历程和触发器.存储历程是编译和存放在服务器中的SQL 代码.它可在今后调用而无需从客户机发送并解析.可以对一个历程举行更改以影响利用它的任何客户机利用程序.触发器功效使一个历程在某个事件发生时被激活,如从表中删除某个记录时,激活呼应的历程.比方,某个作为累计成份的记录被删除时,应当重新举行累计,使累计数反映最新情形.存储历程语言已列入了MySQL 预备实现的筹划.
? ? ■ 视图.视图是一个逻辑概念,其功效像表但本身不是表.它供应了一种查看差别表中的列的途径,在查看时仿佛这些列属于同一个表一样.视图有时也称为虚表.M y S Q L也预备实现视图功效.
? ? ■ 记录级权限和锁定.MySQL 支持各种权限,从全局权限到数据库、表、列的权限.但它不支持记录级的权限.不过,可在利用程序中操纵GET_LOCK( ) 和R E L E A S E _LOCK( ) 函数来实现协同记录锁.这个历程在附录C"运行算符和函数参考"中呼应的项目下介绍.
? ? ■ "- -"作为注释的开始.MySQL 不支持这种注释气势,因为它是一个有歧义的构造,固然自MySQL 3.23 以来,注释可用两个短划线加一个空格开始.更具体的信息,请参阅3 . 7节"加注释".
  以上是“MySQL数据库技术(19)[MySQL防范]”的内容,如果你对以上该文章内容感兴趣,你可以看看七道奇为您推荐以下文章:

  • Windows 搭配 IIS7 PHP MySQL 环境
  • mysql Out of memory (Needed 16777224 bytes)的错误办理
  • mysql提醒[Warning] Invalid (old?) table or database name问题的办理办法
  • mysql启用skip-name-resolve情势时呈现Warning的处理办法
  • mysql启用skip-name-resolve情势时呈现Warning的处理办法
  • MySQL Order By语法介绍
  • <b>MySQL ORDER BY 的实现解析</b>
  • mysql数据库插入速度和读取速度的调整记录
  • MySQL Order By索引优化办法
  • MySQL Order By用法分享
  • mysql #1062 –Duplicate entry ''1'' for key ''PRIMARY''
  • MySQL Order By Rand()效率解析
  • 本文地址: 与您的QQ/BBS好友分享!
    • 好的评价 如果您觉得此文章好,就请您
        0%(0)
    • 差的评价 如果您觉得此文章差,就请您
        0%(0)

    文章评论评论内容只代表网友观点,与本站立场无关!

       评论摘要(共 0 条,得分 0 分,平均 0 分) 查看完整评论
    Copyright © 2020-2022 www.xiamiku.com. All Rights Reserved .