发一篇MySQL中存储程序、函数、触发程序和复制
DBaaS解决方案既可以解决这些问题，又能为客户节约资金。相反作为解决方案提供商，采用DBaaS模式似乎就并不那么有吸引力了，因为与企业内部署软件的解决方案相比，DBaaS意味着更低的利润。 shuixianMySQL5.1存储程序和函数对复制起感化吗？
是的，在存储程序和函数中被实行尺度举动被从主MySQL服务器复制到从服务器。
在主服务器上创立的存储程序和函数能够被复制到从服务器上么？
是的，经由过程一样平常DDL语句实行的存储程序和函数，其在主服务器上的创立被复制到从服务器，以是方针将存在两个服务器上。对存储程序和函数的ALTER和DROP语句也被复制。
举动怎样在已复制的存储程序和函数里产生？
MySQL记录每一个产生在存储程序和函数里的DML事务，并复制这些独自的举动到从服务器。实行存储程序和函数的实在挪用不被复制。
对一同利用存储程序，函数和复制有甚么出格的平安请求么？
是的，由于一个从服务器有权限来实行任何读自立服务器的二进制日记的语句，指定的平安束缚因与复制一同利用的存储程序和函数而存在。假如复制或二进制日记大致上是激活的(为point-in-time恢复的目标)，那末MySQLDBA有两个平安选项可选：
任何想创立存储程序的用户必需被付与SUPER权限。
作为选择，一个DBA能够设置log_bin_trust_routine_creators体系变量为1，它将会同意有尺度CREATEROUTINE权限的人来创立一个存储程序和函数。
对复制存储程序和函数的举动有甚么限定？
嵌进到存储程序中的不断定(随机)或时基行不克不及得当地复制。随机发生的了局，仅因其个性，是你可展望的和不克不及被的确克隆的。因而，复制到从服务器的随机举动将不会镜像那些发生在主服务器上的。注重，声明存储程序或函数为DETERMINISTIC大概在log_bin_trust_routine_creators中设置体系变量为0将会同意随即值操纵被挪用。
别的，时基举动不克不及在从服务器上从头发生，由于在存储程序中经由过程对复制利用的二进制日记来计时如许的时基举动是不成从头发生的，由于该二进制日记仅记录DML事务且不包含计时束缚。
最初，在年夜型DML举动(如多量拔出)中非交互表产生毛病，该非交互表大概履历复制，在复制版的非交互表中主服务器能够被部分地从DML举动更新。可是由于产生的谁人毛病，对从服务器没有更新。对函数的DML举动，事情区将被用IGNORE关头词来实行，以便于在主服务器上招致毛病的更新被疏忽，而且不会招致毛病的更新被复制到从服务器。
事实上，在任何DBaaS中，解决方案提供商对如何管理物理资源都没有控制权，因此MySQL学习教程可能会发现由于DBaaS的局限性使得他们提供给客户的远远小于客户所期望的。 原来的计算字段其实和虚拟字段很像。只是管理方面好了而已，性能方面提高不多。但是SQL2005提供了计算字段的持久化，这就提高了查询的性能，但是会加重insert和update的负担。OLTP慎用。OLAP可以大规模使用。 这就引发了对varchar和char效率讨论的老问题。到底如何分配varchar的数据，是否会出现大规模的碎片？ 如果处理少量数据,比如几百条记录的数据,我不知道这两种情况哪个效率更高,如果处理大量数据呢?比如有表中有20万条记录. 入门没那么困难，精通没那么容易 但换公司用MSSQL2K感觉自己好像根本就不了解MSSQL。什么DTS触发器以前根本没用过。 如果你是从“学习某一种数据库应用软件，从而获得应聘的资本和工作机会”的角度来问的话。 如安全管理、备份恢复、性能监控和调优等，SQL只要熟悉基本操作就可以，只要程序设计部分只要稍加了解即可（如存储过程、触发器等）。
页:
[1]