MYSQL网站制作之MySQL数据目次的布局

DBaaS解决方案既可以解决这些问题，又能为客户节约资金。相反作为解决方案提供商，采用DBaaS模式似乎就并不那么有吸引力了，因为与企业内部署软件的解决方案相比，DBaaS意味着更低的利润。mysql|数据|数据目次MySQL数据目次中包括由服务器办理的一切数据库和表。它们被构造成一个树状布局，该布局是经由过程UNIX或Windows文件体系的条理布局用复杂的体例完成的：
每一个数据库对应当数据目次下的一个目次。
数据库中的表对应数据库目次中的文件。
数据目次还包括几个由服务器天生的形态文件，如日记文件。这些文件供应了关于服务器运作的主要信息，对办理员是有效的，特别是当成绩呈现且试图断定成绩的缘故原由时出格有效。比方，假如某个特定的檠倩盗耸菘猓梢酝ü觳槿罩疚募词侗鹫飧鎏盅岬牟檠?br>
MySQL服务器如何供应对数据的会见

数据目次中的统统都由一个单个的实体举行办理，即MySQL服务器的mysqld。客户机程序不克不及间接利用数据。而服务器供应了会见数据库的独一的保持点，它承当着客户机程序和所需数据之间的前言（拜见0-1）

登录/注册后可看大图

当启动服务器时，假如有任何哀求，它都将翻开日记文件，然后经由过程对收集毗连的监听向数据目次展示收集接口。为了会见数据，客户机创建一个到服务器的毗连，然后转达作为SQL查询的哀求，以完成所希冀的操纵（比方，创立表、选择纪录、更新纪录）。服务器实行每一个操纵并将了局发送回客户机。服务器是多线程的，能够服务于多个并发的客户机的毗连。可是，因为更新操纵一次只能实行一个，因而实践上这些哀求是按次化的，两个客户机决不成能在统一时候修正统一个纪录。
在一般前提下，使服务器承当数据库会见的独一仲裁者将供应对避免各类讹误的包管，这些讹误可招致多个历程同时会见数据库的表。但是，办理员应当晓得：存在着服务器不具有对数据目次独有把持的时代：
什么时候在单个数据目次中运转多个服务器。一般情形下是运转一个单个的服务器来办理主机中的一切数据库，可是运转多个服务器也是大概的。假如如许做能够供应对多个自力的数据目次的会见，则不存在交互感化的成绩。可是，有大概启动多个服务器并在不异的数据目次中指向它们。这是一个好主张，假如您想尝尝它，最好应确保体系供应了优秀的文件锁定功能，不然服务器之间将不克不及和谐地事情。假如将多个服务器同时写进日记文件，则将会使日记文件成为凌乱的来历（而不是有效信息的来历）。
什么时候运转isamchk和myisamchk。isamchk和myisamchk有用程序用于表的保护、妨碍扫除和修复。正如您所推测的，因为这些有用程序能改动表的内容，以是假如在服务器运作的同时同意有用程序对表举行操纵，将引发表的损坏。懂得如何限定这类范例的交互感化以免表损坏是主要的。有关得当利用这些程序的申明，请参阅第13章“数据库保护和修复”。

数据库的暗示法

由MySQL办理的每一个数据库都有本人的数据库目次，它们是数据目次的子目次，与所暗示的数据库有不异的称号。比方，数据库my_db对应于数据库目次DATADIR/my_db。
这个暗示法使得几个数据库级的语句的完成几近是微不足道的。CREATEDATABASEdb_name利用只同意对MySQL服务器用户（服务器运转的UNIX用户）举行会见的一切权和体例，并在数据目次中创立一个空目次db_name。这等价于以服务器主机中的服务器用户的身份经由过程实行以下命令手工创立数据库：
%mkdirDATADIR/db_name创立数据库目次
%chmod700DATADIR/db_name使它仅对MySQL服务器用户可会见
经由过程空目次暗示新数据库的办法与其他数据库体系完整分歧，那些数据库体系乃至要为“空”数据库创立很多把持文件或体系文件。
DROPDATABASE语句也很简单完成。DROPDATABASEdb_name删除数据目次中的db_name目次和个中的一切表文件。这个语句相似于以下命令：
%rm-rfDATADIR/db_name
其区分是，服务器只删除带有表的扩大名的文件。假如已在该数据库目次中创立了其他的文件，服务器将使它们坚持完全，而且不删除该目次自己。
SHOWDATABASE只不外是对应位于数据目次中的子目次称号的一个列表。有些数据库体系必要保存一个列出一切必要保护的数据库的主表，可是，在MySQL中没有如许的布局。因为数据目次布局的复杂性，数据库的列表是隐含在该数据目次的内容中的，像主表如许的
表大概会引发不用要的开支。

数据库表的暗示法

数据库中的每一个表在数据库目次中都作为三个文件存在：一个格局（形貌）文件、一个数据文件和一个索引文件。每一个文件的基名是该表名，扩大名指明该文件的范例。扩大名如表10-1所示。数据和索引文件的扩大名指明该表是不是利用较老的ISAM索引或较新的MyISAM索引。

登录/注册后可看大图

当公布界说一个表布局的CREATETABLEtbl_name语句时，服务器创立tbl_name.frm文件，它包括该布局的外部编码。该语句还创立空的数据文件和索引文件，这些文件的初始信息标明没有纪录和索引（假如CREATETABLE语句包括索引申明，则该索引文件将反应这些索引）。形貌表的文件的一切权和体例被设置为只同意对MySQL服务器用户的会见。
当公布ALTERTABLE语句时，服务器对tbl_name.frm从头编码并修正数据文件和索引文件的内容以反应由该语句标明的布局变更。关于CREATE和DROPINDEX也是云云，由于服务器以为它们等价于ALTERTABLE语句。DROPTABLE删除代表该表的三个文件。
只管能够经由过程删除数据库目次中的对应某个表的三个文件来删除该表，但不克不及手工创立或变动表。比方，假如my_db是以后的数据库，DROPTABLEmy_tbl大抵等价于以下命令：
%rm-fDATADIR/my_db_tbl.*
来自于SHOWTABLESmy_db的输入了局恰是my_db数据库目次中.frm文件基名的一个列表。某些数据库体系保护一个列出了数据库中的一切表的挂号。但MySQL不如许做，由于没有需要，这个“挂号”隐含在了数据目次的布局中。

数据库和表定名中的操纵体系束缚

MySQL具有对数据库和表定名的一样平常划定规矩：
名字能够由以后字符会合的字母数字字符和下划线和美圆标记（‘_’和‘$’）构成。
名字最长可达64个字符。
可是，因为数据库和表的名字对应于目次和文件名，因而，对数据库运转的操纵体系能够施加别的的束缚。
起首，将数据库和表名限定为文件名中的正当字符。比方，依照MySQL的划定规矩，名字中同意利用‘$’，可是，假如操纵体系不同意利用它，则不克不及在目次名或表名中利用。实践上，这与UNIX或Windows有关。大概会碰到的最年夜坚苦是在举行数据库办理时从外壳程序
中间接定名。比方，假如给某个数据库界说了诸如$my_db的名字，该名字包含美圆标记，对来自外壳程序命令行的该名字的任何援用都可由外壳程序注释为一个变量援用：
%ls$my_db
my_db:Undefinedvariable
假如这类情形产生，必需将‘$’字符换码，或利用引号来作废其特别的寄义：
%ls$my_db
%ls$my_db
假如要利用引号，则应利用单引号。双引号不克不及作废对变量的注释。
第二，只管MySQL同意数据库和表的名字最年夜长度为64个字符，但名字的长度也要遭到操纵体系所同意长度的限定。一般，这不是甚么成绩，只管在UNIX中您大概会进进有14个字符限定的旧版本SystemV-ish体系中。在这类情形下，数据库名字的无效限定为14个字符，表名的限定为10个字符，由于暗示表的文件称号可用一个句点和三字符的扩大名闭幕。
第三，基本文件体系的巨细写敏理性影响您对数据库和表的定名及援用。假如文件体系是辨别巨细写的（如UNIX），则my_tbl和MY_TBL这两个名字触及分歧的表。假如文件体系不是辨别巨细写的（如Windows），则my_tbl和MY_TBL是统一个表。您应该寄望是不是利用了UNIX服务器来开辟数据库，假如有大概的话，在某时应将该数据库移到Windows服务器上。

体系功能的数据目次布局的寄义

数据目次的布局易于了解，由于它利用了文件体系的条理布局的体例。同时，该布局具有特定的功能寄义，特别是关于翻开暗示数据库表文件的操纵。
这类数据目次布局的一个成果是，因为表由多个文件来暗示，因而每一个翻开的表都必要多个文件形貌符，而不是一个。服务器智能化地高速缓存这些形貌符，可是一个忙碌的服务器大概会很容易地耗尽形貌符资本，假如服务器同时为很多并发的客户机毗连服务或运转引
用多个表的庞大查询的话。文件形貌符在很多体系中都是匮乏的资本，特别是将缺省的总历程（per-process）限定设置得相称低的体系。第11章“惯例的MySQL办理”将供应有关估量所需形貌符数目的信息，和在必要时从头设置服务器或操纵体系的信息。
由表本人的文件暗示每一个表的另外一个成果是，表的翻开工夫随表的数目而增添。翻开表的操纵映照成由操纵体系供应的文件翻开操纵，因而将遭到体系的目次查找程序（directory-lookuproutine）效力的影响。一般这不是个成绩，可是，假如在数据库中必要大批的表时，它则是个要思索的成绩。
比方，假如想要失掉10000个表，则数据库目次中应当包括30000个文件。关于这么多的文件，将会引发因为文件翻开操纵所消费的工夫而使运转速率下降（Linuxext2和Solaris文件体系存在这个成绩）。假如这个成绩触及到好坏干系，则应依据使用程序的必要明智地从头思索表的布局，从而从头构造这些表。应检察一下是不是真的必要这么多的表，由于偶然使用程序会不用要地滋生很多表。为每一个用户创立一个单个表的使用程序将招致很多表的发生，实在一切这些表都有不异的布局。假如您想将这些表兼并成一个表，能够经由过程增添另外一列以标识每行所利用的用户来到达目标。假如这能使表的数目分明削减，则会响应进步使用程序的功能。
在数据库计划阶段，您必需思索这个特定的阶段关于一个给定的使用程序是不是是值得的。不按下面所形貌的办法来兼并表的缘故原由以下：
增年夜的磁盘空间的需求。兼并表是为了削减所需表的数目（削减表翻开的工夫），但增添了另外一列内容（增添磁盘空间的需求）。这是典范的空间与工夫的折中，您必要决意哪一个要素更主要。假如以为速率极其主要，您也许乐意就义一点分外的磁盘空间。假如空间太严重，则只能忍耐利用多个表的工夫。
平安性思索。这些大概会束缚您的才能或对表兼并的希望。每一个用户分离利用独自的表的一个缘故原由是：使只要具有表级权限的用户才干对每一个表举行会见。假如兼并了表，则一切用户数据都将在统一个表中呈现。
MySQL没无限制一个已知用户对特定行的会见的划定，因而，假如没有保密会见把持就不克不及兼并表。另外一方面，假如一切的数据会见都由使用程序把持（用户不成能间接毗连到服务器），则能够兼并表并利用使用程序的逻辑强迫兼并后的行级会见。
MySQL关于表的巨细有其本人外部的限定，可是，因为它将表暗示为文件，MySQL还将遭到文件尺寸最年夜值的限定，该最年夜值是由操纵体系给出的。因而，无效的表尺寸最年夜值要小于MySQL的外部限定和体系文件尺寸的限定。
一般，跟着工夫的推移，对尺寸巨细的束缚将有所和缓。比方，IBMAIX4.1有2GB文件巨细的限定，可是在AIX4.2中该限定值约莫为64GB。在MySQL中外部的表巨细限定值也跟着最新版本的呈现而增添。在3.23系列之前，外部的限定值为4GB。从3.23系列起，该限定值约莫为9000000太字节。表10-2申明了MySQL外部的表巨细限定和AIX文件巨细限定如何互相感化来断定无效的表巨细的最年夜值。相似的互相感化也可使用于其他的操纵体系。

登录/注册后可看大图

MySQL的形态文件

除数据库目次外，MySQL数据目次还包括很多形态文件。表10-3归纳综合先容了这些文件。年夜多半形态文件的缺省称号从服务器主机名字中天生，在此表中暗示为HOSTNAME。
表10-3MySQL形态文件

文件范例缺省名文件内容历程IDHOSTNAME.pid服务器历程ID毛病日记HOSTNAME.err启动和封闭事务和毛病形态惯例日记HOSTNAME.log毗连/断开事务和查询信息更新日记HOSTNAME.nnn修正表的内容或布局的一切查询的文本服务器在启动时将它的历程ID（PID）写进PID文件，并在封闭时删除该文件。PID文件是一种办法，用这类办法，其他的历程能够找到该服务器。比方，假如您在体系封闭时运转mysql.server剧本来封闭MySQL服务器，则该剧本将反省PID文件以断定它必要哪一个历程来发送一个停止旌旗灯号。
毛病日记由safe_mysqld发生，作为服务器尺度毛病输入了局的重定向，它包括服务器写进stderr的一切动静。这意味着仅当经由过程挪用safe_mysqld启动服务器时，毛病日记才存在（总之，这是启动服务器的首选办法，由于，假如因为一个毛病使毛病日记存在，则
safe_mysqld将从头启动服务器）
惯例日记和更新日记是可选的，能够用--log和--log-update服务器选项开启必要的日记范例。
惯例历程供应有关服务器运作的惯例信息：谁从那里举行了毗连，和他们公布了甚么查询。更新日记也供应查询信息，但仅仅是修正过的数据库内容的查询信息。更新日记的内容是一些SQL语句，这些语句能够经由过程将它们输出到mysql客户机程序来运转。假如呈现崩
溃且必需转到备份文件时，更新日记将是有效的，由于您可以经由过程将更新日记输出到服务器来反复这些自溃散以来所完成的更新操纵。这将使得数据库恢复到溃散产生时所处的形态上。
上面是一个实例，它是作为一个短客户时机话的了局呈现在惯例日记中的信息中的，这个会话在test数据库中创立一个表，并拔出一行到该表中，然后删除该表：

登录/注册后可看大图

惯例日记包括日期和工夫、服务器线程ID、事务范例和特定事务信息的列。
统一个会话呈现在以下的更新日记中：

登录/注册后可看大图

关于更新日记，日记的扩大格局是可用的，即便是用--log-long-format选项。扩大的日记供应有关谁什么时候公布查询的信息。固然，这将利用更多的磁盘空间，可是，假如您不将更新日记的内容与惯例日记中的毗连事务相接洽就想晓得谁正在做甚么的话，扩大日记也许是可用的。
关于方才显现出的会话，扩大日记将发生以下信息：

登录/注册后可看大图

确保日记文件的平安且不被用户恣意读取是个好注重。惯例日记和更新日记都包括有诸如口令如许的敏感信息，这是由于它们包括了查询的文本。上面是您不想让任何人都能读取的日记项，由于它显现了root用户的口令：

登录/注册后可看大图

有关反省可设置数据目次允许权的信息，请参阅第12章。数据目次平安的冗长指令由以下命令构成：
%chmod700DATADIR
以具有该数据目次的UNIX用户身份来运转此命令。还要确保服务器以该用户身份运转，不然此命令不但将其他用户排挤在该数据目次以外（您想要的），还将制止服务器会见您的数据库（您不要的）。
形态文件呈现在数据目次的第一流，就像数据库目次一样，因而您大概会想到那些文件的名字是不是会互相搅浑大概被误以为是数据库名（比方，当服务器正在实行SHOWDATABASE语句时）。谜底是：不会的。形态和日记信息存储在文件中，而数据库是目次，因而可实行程序能够将它们与一个复杂的stat()挪用相区分（是服务器告知它们如何辨别的）。假如您正在监督数据目次，则能够经由过程利用ls-l将形态文件从数据库目次中辨别开来，而且反省该形式信息的第一个字符以检察它是‘-’仍是‘d’：

登录/注册后可看大图

您还能够经由过程检察名字而复杂地告之：一切形态文件名都包括一个句点，可是数据库目次名没有句点（句点不是数据库名的正当字符）。
有关日记文件保护和轮回手艺的信息，请参阅第11章的内容。
这种服务也提供了足够的监控功能来跟踪性能和使用情况，在问题发生时将发出通知并生成一定深度的分析报告。

备份方面可能还是一个老大难的问题。不能单独备份几个表总是感觉不爽。灵活备份的问题不知道什么时候才能解决。

而SQLServer如果能像Oracle一样可以为登陆分配如：5%的cpu，10%的内存。就可以解决这个漏洞。

呵呵，这就是偶想说的

分区表是个亮点！从分区表也能看出微软要做大作强SQLServer的信心。资料很多，这里不详细说。但是重点了解的是：现在的SQLServer2005的表，都是默认为分区表的。因为它要支持滑动窗口的这个特性。这种特性对历史数据和实时数据的处理是很有帮助的。

学习SQL语言的话如果要学会去做网站就不是很难!但是要做数据库管理的话就有难度了!

原来的计算字段其实和虚拟字段很像。只是管理方面好了而已，性能方面提高不多。但是SQL2005提供了计算字段的持久化，这就提高了查询的性能，但是会加重insert和update的负担。OLTP慎用。OLAP可以大规模使用。

多走走一此相关论坛，多看一些实例开发，多交流0经验，没什么的，我也是刚学没多久!加油

原理很简单，对要求长时间计算某一时间点的报表生成和防用户操作错误很有帮助。但是比起Oracle10g的闪回技术还是细粒度不够。可惜！

两个月啃那本sqlserver2005技术内部-存储引擎，花了几个月啃四本书

如果我们从集合论（关系代数）的角度来看，一张数据库的表就是一组数据元的关系，而每个SQL语句会改变一种或数种关系，从而产生出新的数据元的关系（即产生新的表）。

分区表效率问题肯定是大家关心的问题。在我的试验中，如果按照分区字段进行的查询（过滤）效率会高于未分区表的相同语句。但是如果按照非分区字段进行查询，效率会低于未分区表的相同语句。