（1）系统服务优化，把MySQL的key_buffer、cache_buffer、query_cache等增加容量
（2）给所有经常查询的字段增加适当的索引
（3）优化SQL语句，减少Ditinct、Group、Join等等语句的操作
② 系统数据库优化问题。如下：
实例讲解MYSQL数据库的查询优化技术 作者：佚名 文章来源：未知 点击数：2538 更新时间：2006-1-19 数据库系统是管理信息系统的核心，基于数据库的联机事务处理（OLTP）以及联机分析处理(OLAP)是银行、企业、政府等部门最为重要的计算机应用之一。从大多数系统的应用实例来看，查询操作在各种数据库操作中所占据的比重最大，而查询操作所基于的SELECT语句在SQL语句中又是代价最大的语句。举例来说，如果数据的量积累到一定的程度，比如一个银行的账户数据库表信息积累到上百万甚至上千万条记录，全表扫描一次往往需要数十分钟，甚至数小时。如果采用比全表扫描更好的查询策略，往往可以使查询时间降为几分钟，由此可见查询优化技术的重要性。笔者在应用项目的实施中发现，许多程序员在利用一些前端数据库开发工具（如PowerBuilder、Delphi等）开发数据库应用程序时，只注重用户界面的华丽，并不重视查询语句的效率问题，导致所开发出来的应用系统效率低下，资源浪费严重。因此，如何设计高效合理的查询语句就显得非常重要。本文以应用实例为基础，结合数据库理论，介绍查询优化技术在现实系统中的运用。分析问题许多程序员认为查询优化是DBMS（数据库管理系统）的任务，与程序员所编写的SQL语句关系不大，这是错误的。一个好的查询计划往往可以使程序性能提高数十倍。查询计划是用户所提交的SQL语句的集合，查询规划是经过优化处理之后所产生的语句集合。DBMS处理查询计划的过程是这样的：在做完查询语句的词法、语法检查之后，将语句提交给DBMS的查询优化器，优化器做完代数优化和存取路径的优化之后，由预编译模块对语句进行处理并生成查询规划，然后在合适的时间提交给系统处理执行，最后将执行结果返回给用户。在实际的数据库产品(如Oracle、Sybase等)的高版本中都是采用基于代价的优化方法，这种优化能根据从系统字典表所得到的信息来估计不同的查询规划的代价，然后选择一个较优的规划。虽然现在的数据库产品在查询优化方面已经做得越来越好，但由用户提交的SQL语句是系统优化的基础，很难设想一个原本糟糕的查询计划经过系统的优化之后会变得高效，因此用户所写语句的优劣至关重要。系统所做查询优化我们暂不讨论，下面重点说明改善用户查询计划的解决方案。解决问题下面以关系数据库系统Informix为例，介绍改善用户查询计划的方法。1．合理使用索引索引是数据库中重要的数据结构，它的根本目的就是为了提高查询效率。现在大多数的数据库产品都采用IBM最先提出的ISAM索引结构。索引的使用要恰到好处，其使用原则如下：●在经常进行连接，但是没有指定为外键的列上建立索引，而不经常连接的字段则由优化器自动生成索引。●在频繁进行排序或分组（即进行group by或order by操作）的列上建立索引。●在条件表达式中经常用到的不同值较多的列上建立检索，在不同值少的列上不要建立索引。比如在雇员表的“性别”列上只有“男”与“女”两个不同值，因此就无必要建立索引。如果建立索引不但不会提高查询效率，反而会严重降低更新速度。●如果待排序的列有多个，可以在这些列上建立复合索引（compound index）。●使用系统工具。如Informix数据库有一个tbcheck工具，可以在可疑的索引上进行检查。在一些数据库服务器上，索引可能失效或者因为频繁操作而使得读取效率降低，如果一个使用索引的查询不明不白地慢下来，可以试着用tbcheck工具检查索引的完整性，必要时进行修复。另外，当数据库表更新大量数据后，删除并重建索引可以提高查询速度。2．避免或简化排序应当简化或避免对大型表进行重复的排序。当能够利用索引自动以适当的次序产生输出时，优化器就避免了排序的步骤。以下是一些影响因素：●索引中不包括一个或几个待排序的列；●group by或order by子句中列的次序与索引的次序不一样；●排序的列来自不同的表。为了避免不必要的排序，就要正确地增建索引，合理地合并数据库表（尽管有时可能影响表的规范化，但相对于效率的提高是值得的）。如果排序不可避免，那么应当试图简化它，如缩小排序的列的范围等。3．消除对大型表行数据的顺序存取在嵌套查询中，对表的顺序存取对查询效率可能产生致命的影响。比如采用顺序存取策略，一个嵌套3层的查询，如果每层都查询1000行，那么这个查询就要查询10亿行数据。避免这种情况的主要方法就是对连接的列进行索引。例如，两个表：学生表（学号、姓名、年龄……）和选课表（学号、课程号、成绩）。如果两个表要做连接，就要在“学号”这个连接字段上建立索引。还可以使用并集来避免顺序存取。尽管在所有的检查列上都有索引，但某些形式的where子句强迫优化器使用顺序存取。下面的查询将强迫对orders表执行顺序操作：SELECT ＊ FROM orders WHERE (customer_num=104 AND order_num>1001) OR order_num=1008虽然在customer_num和order_num上建有索引，但是在上面的语句中优化器还是使用顺序存取路径扫描整个表。因为这个语句要检索的是分离的行的集合，所以应该改为如下语句：SELECT ＊ FROM orders WHERE customer_num=104 AND order_num>1001UNIONSELECT ＊ FROM orders WHERE order_num=1008 这样就能利用索引路径处理查询。 4．避免相关子查询一个列的标签同时在主查询和where子句中的查询中出现，那么很可能当主查询中的列值改变之后，子查询必须重新查询一次。查询嵌套层次越多，效率越低，因此应当尽量避免子查询。如果子查询不可避免，那么要在子查询中过滤掉尽可能多的行。5．避免困难的正规表达式MATCHES和LIKE关键字支持通配符匹配，技术上叫正规表达式。但这种匹配特别耗费时间。例如：SELECT ＊ FROM customer WHERE zipcode LIKE “98_ _ _” 即使在zipcode字段上建立了索引，在这种情况下也还是采用顺序扫描的方式。如果把语句改为SELECT ＊ FROM customer WHERE zipcode >“98000”，在执行查询时就会利用索引来查询，显然会大大提高速度。 另外，还要避免非开始的子串。例如语句：SELECT ＊ FROM customer WHERE zipcode[2，3]>“80”，在where子句中采用了非开始子串，因而这个语句也不会使用索引。 6．使用临时表加速查询把表的一个子集进行排序并创建临时表，有时能加速查询。它有助于避免多重排序操作，而且在其他方面还能简化优化器的工作。例如：SELECT cust.name，rcvbles.balance，……other columns FROM cust，rcvbles WHERE cust.customer_id = rcvlbes.customer_id AND rcvblls.balance>0 AND cust.postcode>“98000” ORDER BY cust.name 如果这个查询要被执行多次而不止一次，可以把所有未付款的客户找出来放在一个临时文件中，并按客户的名字进行排序： SELECT cust.name，rcvbles.balance，……other columns FROM cust，rcvbles WHERE cust.customer_id = rcvlbes.customer_id AND rcvblls.balance>0 ORDER BY cust.name INTO TEMP cust_with_balance 然后以下面的方式在临时表中查询：SELECT ＊ FROM cust_with_balance WHERE postcode>“98000” 临时表中的行要比主表中的行少，而且物理顺序就是所要求的顺序，减少了磁盘I/O，所以查询工作量可以得到大幅减少。注意：临时表创建后不会反映主表的修改。在主表中数据频繁修改的情况下，注意不要丢失数据。 7．用排序来取代非顺序存取非顺序磁盘存取是最慢的操作，表现在磁盘存取臂的来回移动。SQL语句隐藏了这一情况，使得我们在写应用程序时很容易写出要求存取大量非顺序页的查询。有些时候，用数据库的排序能力来替代非顺序的存取能改进查询。实例分析下面我们举一个制造公司的例子来说明如何进行查询优化。制造公司数据库中包括3个表，模式如下所示：1．part表 零件号零件描述其他列 （part_num）（part_desc）（other column） 102，032Seageat 30G disk…… 500，049Novel 10M network card…… …… 2．vendor表 厂商号厂商名其他列 （vendor _num）（vendor_name） （other column） 910，257Seageat Corp…… 523，045IBM Corp…… …… 3．parven表 零件号厂商号零件数量 （part_num）（vendor_num）（part_amount） 102，032910，2573,450,000 234，423321，0014，000，000 …… 下面的查询将在这些表上定期运行，并产生关于所有零件数量的报表： SELECT part_desc，vendor_name，part_amount FROM part，vendor，parven WHERE part.part_num=parven.part_num AND parven.vendor_num = vendor.vendor_num ORDER BY part.part_num 如果不建立索引，上述查询代码的开销将十分巨大。为此，我们在零件号和厂商号上建立索引。索引的建立避免了在嵌套中反复扫描。关于表与索引的统计信息如下： 表行尺寸行数量每页行数量数据页数量 （table）(row size)（Row count）（Rows/Pages）（Data Pages） part15010，00025400 Vendor1501，000 2540 Parven13 15，000300 50 索引键尺寸每页键数量页面数量 （Indexes）(Key Size)（Keys/Page)(Leaf Pages） part450020 Vendor45002 Parven825060 看起来是个相对简单的3表连接，但是其查询开销是很大的。通过查看系统表可以看到，在part_num上和vendor_num上有簇索引，因此索引是按照物理顺序存放的。parven表没有特定的存放次序。这些表的大小说明从缓冲页中非顺序存取的成功率很小。此语句的优化查询规划是：首先从part中顺序读取400页，然后再对parven表非顺序存取1万次，每次2页（一个索引页、一个数据页），总计2万个磁盘页，最后对vendor表非顺序存取1.5万次，合3万个磁盘页。可以看出在这个索引好的连接上花费的磁盘存取为5.04万次。实际上，我们可以通过使用临时表分3个步骤来提高查询效率： 1．从parven表中按vendor_num的次序读数据： SELECT part_num，vendor_num，price FROM parven ORDER BY vendor_num INTO temp pv_by_vn 这个语句顺序读parven（50页），写一个临时表（50页），并排序。假定排序的开销为200页，总共是300页。 2．把临时表和vendor表连接，把结果输出到一个临时表，并按part_num排序： SELECT pv_by_vn，＊ vendor.vendor_num FROM pv_by_vn，vendor WHERE pv_by_vn.vendor_num=vendor.vendor_num ORDER BY pv_by_vn.part_num INTO TMP pvvn_by_pn DROP TABLE pv_by_vn 这个查询读取pv_by_vn(50页)，它通过索引存取vendor表1.5万次，但由于按vendor_num次序排列，实际上只是通过索引顺序地读vendor表（40＋2=42页），输出的表每页约95行，共160页。写并存取这些页引发5＊160=800次的读写，索引共读写892页。3．把输出和part连接得到最后的结果： SELECT pvvn_by_pn.＊，part.part_descFROM pvvn_by_pn，part WHERE pvvn_by_pn.part_num=part.part_num DROP TABLE pvvn_by_pn 这样，查询顺序地读pvvn_by_pn(160页)，通过索引读part表1.5万次，由于建有索引，所以实际上进行1772次磁盘读写，优化比例为30∶1。笔者在Informix DynamicSever上做同样的实验，发现在时间耗费上的优化比例为5∶1(如果增加数据量，比例可能会更大)。 小结20％的代码用去了80％的时间，这是程序设计中的一个着名定律，在数据库应用程序中也同样如此。我们的优化要抓住关键问题，对于数据库应用程序来说，重点在于SQL的执行效率。查询优化的重点环节是使得数据库服务器少从磁盘中读数据以及顺序读页而不是非顺序读页。
③ 数据库 大数据操作
下面以关系数据库系统Informix为例，介绍改善用户查询计划的方法。 1．合理使用索引 索引是数据库中重要的数据结构，它的根本目的就是为了提高查询效率。现在大多数的数据库产品都采用IBM最先提出的ISAM索引结构。索引的使用要恰到好处，其使用原则如下： ●在经常进行连接，但是没有指定为外键的列上建立索引，而不经常连接的字段则由优化器自动生成索引。 ●在频繁进行排序或分组（即进行group by或order by操作）的列上建立索引。 ●在条件表达式中经常用到的不同值较多的列上建立检索，在不同值少的列上不要建立索引。比如在雇员表的“性别”列上只有“男”与“女”两个不同值，因此就无必要建立索引。如果建立索引不但不会提高查询效率，反而会严重降低更新速度。 ●如果待排序的列有多个，可以在这些列上建立复合索引（compound index）。 ●使用系统工具。如Informix数据库有一个tbcheck工具，可以在可疑的索引上进行检查。在一些数据库服务器上，索引可能失效或者因为频繁操作而使得读取效率降低，如果一个使用索引的查询不明不白地慢下来，可以试着用tbcheck工具检查索引的完整性，必要时进行修复。另外，当数据库表更新大量数据后，删除并重建索引可以提高查询速度。 2．避免或简化排序 应当简化或避免对大型表进行重复的排序。当能够利用索引自动以适当的次序产生输出时，优化器就避免了排序的步骤。以下是一些影响因素： ●索引中不包括一个或几个待排序的列； ●group by或order by子句中列的次序与索引的次序不一样； ●排序的列来自不同的表。 为了避免不必要的排序，就要正确地增建索引，合理地合并数据库表（尽管有时可能影响表的规范化，但相对于效率的提高是值得的）。如果排序不可避免，那么应当试图简化它，如缩小排序的列的范围等。 3．消除对大型表行数据的顺序存取 在嵌套查询中，对表的顺序存取对查询效率可能产生致命的影响。比如采用顺序存取策略，一个嵌套3层的查询，如果每层都查询1000行，那么这个查询就要查询10亿行数据。避免这种情况的主要方法就是对连接的列进行索引。例如，两个表：学生表（学号、姓名、年龄……）和选课表（学号、课程号、成绩）。如果两个表要做连接，就要在“学号”这个连接字段上建立索引。 还可以使用并集来避免顺序存取。尽管在所有的检查列上都有索引，但某些形式的where子句强迫优化器使用顺序存取。下面的查询将强迫对orders表执行顺序操作： SELECT ＊ FROM orders WHERE (customer_num=104 AND order_num>1001) OR order_num=1008 虽然在customer_num和order_num上建有索引，但是在上面的语句中优化器还是使用顺序存取路径扫描整个表。因为这个语句要检索的是分离的行的集合，所以应该改为如下语句： SELECT ＊ FROM orders WHERE customer_num=104 AND order_num>1001 UNION SELECT ＊ FROM orders WHERE order_num=1008 这样就能利用索引路径处理查询。 4．避免相关子查询 一个列的标签同时在主查询和where子句中的查询中出现，那么很可能当主查询中的列值改变之后，子查询必须重新查询一次。查询嵌套层次越多，效率越低，因此应当尽量避免子查询。如果子查询不可避免，那么要在子查询中过滤掉尽可能多的行。 5．避免困难的正规表达式 MATCHES和LIKE关键字支持通配符匹配，技术上叫正规表达式。但这种匹配特别耗费时间。例如：SELECT ＊ FROM customer WHERE zipcode LIKE “98_ _ _” 即使在zipcode字段上建立了索引，在这种情况下也还是采用顺序扫描的方式。如果把语句改为SELECT ＊ FROM customer WHERE zipcode >“98000”，在执行查询时就会利用索引来查询，显然会大大提高速度。 另外，还要避免非开始的子串。例如语句：SELECT ＊ FROM customer WHERE zipcode[2，3]>“80”，在where子句中采用了非开始子串，因而这个语句也不会使用索引。 6．使用临时表加速查询 把表的一个子集进行排序并创建临时表，有时能加速查询。它有助于避免多重排序操作，而且在其他方面还能简化优化器的工作。例如： SELECT cust.name，rcvbles.balance，……other columns FROM cust，rcvbles WHERE cust.customer_id = rcvlbes.customer_id AND rcvblls.balance>0 AND cust.postcode>“98000” ORDER BY cust.name 如果这个查询要被执行多次而不止一次，可以把所有未付款的客户找出来放在一个临时文件中，并按客户的名字进行排序： SELECT cust.name，rcvbles.balance，……other columns FROM cust，rcvbles WHERE cust.customer_id = rcvlbes.customer_id AND rcvblls.balance>0 ORDER BY cust.name INTO TEMP cust_with_balance 然后以下面的方式在临时表中查询： SELECT ＊ FROM cust_with_balance WHERE postcode>“98000” 临时表中的行要比主表中的行少，而且物理顺序就是所要求的顺序，减少了磁盘I/O，所以查询工作量可以得到大幅减少。 注意：临时表创建后不会反映主表的修改。在主表中数据频繁修改的情况下，注意不要丢失数据。 7．用排序来取代非顺序存取 非顺序磁盘存取是最慢的操作，表现在磁盘存取臂的来回移动。SQL语句隐藏了这一情况，使得我们在写应用程序时很容易写出要求存取大量非顺序页的查询。 有些时候，用数据库的排序能力来替代非顺序的存取能改进查询。 实例分析 下面我们举一个制造公司的例子来说明如何进行查询优化。制造公司数据库中包括3个表，模式如下所示： 1．part表 零件号?????零件描述????????其他列 （part_num）?（part_desc）??????（other column） 102，032???Seageat 30G disk?????…… 500，049???Novel 10M network card??…… …… 2．vendor表 厂商号??????厂商名??????其他列 （vendor _num）?（vendor_name） （other column） 910，257?????Seageat Corp???…… 523，045?????IBM Corp?????…… …… 3．parven表 零件号?????厂商号?????零件数量 （part_num）?（vendor_num）?（part_amount） 102，032????910，257????3,450,000 234，423????321，001????4，000，000 …… 下面的查询将在这些表上定期运行，并产生关于所有零件数量的报表： SELECT part_desc，vendor_name，part_amount FROM part，vendor，parven WHERE part.part_num=parven.part_num AND parven.vendor_num = vendor.vendor_num ORDER BY part.part_num 如果不建立索引，上述查询代码的开销将十分巨大。为此，我们在零件号和厂商号上建立索引。索引的建立避免了在嵌套中反复扫描。关于表与索引的统计信息如下： 表?????行尺寸???行数量?????每页行数量???数据页数量 （table）?(row size)?（Row count）?（Rows/Pages）?（Data Pages） part????150?????10，000????25???????400 Vendor???150?????1，000???? 25???????40 Parven???13????? 15，000????300?????? 50 索引?????键尺寸???每页键数量???页面数量 （Indexes）?(Key Size)?（Keys/Page)???(Leaf Pages） part?????4??????500???????20 Vendor????4??????500???????2 Parven????8??????250???????60 看起来是个相对简单的3表连接，但是其查询开销是很大的。通过查看系统表可以看到，在part_num上和vendor_num上有簇索引，因此索引是按照物理顺序存放的。parven表没有特定的存放次序。这些表的大小说明从缓冲页中非顺序存取的成功率很小。此语句的优化查询规划是：首先从part中顺序读取400页，然后再对parven表非顺序存取1万次，每次2页（一个索引页、一个数据页），总计2万个磁盘页，最后对vendor表非顺序存取1.5万次，合3万个磁盘页。可以看出在这个索引好的连接上花费的磁盘存取为5.04万次。
④ 数据库性能优化主要包括哪些方面
包括网络、硬件、操作系统、数据库参数和应用程序。
数据库的优化通常可以通过对网络、硬件、操作系统、数据库参数和应用程序的优化来进行。最常见的优化手段就是对硬件的升级。
根据统计，对网络、硬件、操作系统、数据库参数进行优化所获得的性能提升，全部加起来只占数据库系统性能提升的40%左右，其余的60%系统性能提升来自对应用程序的优化。许多优化专家认为，对应用程序的优化可以得到80%的系统性能的提升。
(4)数据库专业par法则扩展阅读
数据库性能优化法则归纳为5个层次：
1、减少数据访问（减少磁盘访问）
2、返回更少数据（减少网络传输或磁盘访问）
3、减少交互次数（减少网络传输）
4、减少服务器CPU开销（减少CPU及内存开销）
5、利用更多资源（增加资源）
由于每一层优化法则都是解决其对应硬件的性能问题，所以带来的性能提升比例也不一样。传统数据库系统设计是也是尽可能对低速设备提供优化方法，因此针对低速设备问题的可优化手段也更多，优化成本也更低。
任何一个SQL的性能优化都应该按这个规则由上到下来诊断问题并提出解决方案，而不应该首先想到的是增加资源解决问题。
⑤ PAR法则中的三个字母分别代表( )。
PAR法则是在制作简历时的一个原则，P代表problem问题，就是个人背景和工作经历等的总体概述；A代表action行动，及你从事的工作内容等；R代表result结果，也就是说你以前取得的业绩、成功等。
⑥ 如何学习数据库知识
要说数据库，一般以SQL Server作为入门的学科，它适合中小型项目开发，而现在比较流行于大型开发的有:
Oracle
现在具有企业大型软件的绝对占有率
DB2 在以IBM服务的公司以及单位（中国银行）
MySql 相对不是很正式的开发，使用MySql
当然还有一些：Access(桌面数据库),FoxPro(中国教育),Informix的数据库系统.
刚开始入门的时候可以找点视频教程来学习，视频教程一般讲得比较好，但不要企图于通过它达到比较高的水平。然后要学会将自己所知道的去实践，多实践。当觉得实践到一定程度而没有什么冲劲了，就去学习理论，当觉得理论知识需要发挥的时候就去实践，时间的周期不一定，没有什么定论，但自己的时间安排需要定论就可以了。
我一直都认为在计算机行业要学会一门技术太简单了，但如果要把技术发挥到一定程度就有难处了，一定程度是什么意思，就是把技术如何发挥到具体的业务之中，会动脑筋去思考，而把技术作为相对次要的东西了。
数据库的DBA人员需要兼有系统分析员和运筹学的业务素质。在技术上讲，我个人认为数据库的前续学科是“数据结构”。
我现在刚学SQL Server一段时间,就自己的感想谈谈:
1.数据库是非常快的数据处理程序,其内在的本质依旧是"文件".因为
Windows操作系统管理机制就有:磁盘、文件、目录。Linux的方式只有文件。所以数据库重本质的角度来说是一种平台软件，是将文件翻译成逻辑语言的软件，成为我们软件程序数据交换的中心，为什么那，一个很重要的原因就是“快”，还有就是“安全”、“集成”等等。因为以前的语言程序要处理数据要编写大量算法十分麻烦而且很容易出错等等。大家就想到集成了。。。。。
2.其实，要谈到操作数据库，简单的就太简单了，但是数据库最难的不是操作，而是在数据库的设计上。一个大型程序设计者肯定是一个数据库的高手，因为大型程序要死板地去完成它是非常困难和不理智也是不安全不稳定的，我们要充分利用自己所有的能力去挖掘其数据之间的奥秘，然后体系化数据库结构，相当于在数据库中如何层次化地建立数据结构。将需求中的矛盾事物改变成可以相互融合的。
我说的数据库操作简单是指一般操作，如果难的操作还是有点技术的，但还是难不到那里去。下面我把我的一个小数据库程序给你看看：（下面这个程序已经建立数据库library，然后用dbo用户建立了表relatBook，并将表的第一个字段设置为“主键”PK）
该程序想说的第一点是：程序按照标准用户写入法则写入。
另外就是在执行多个操作的时候每一步骤的操作我们都必须为其设置错误的回滚操作。所以程序前两个段落都是一样的，在插入的时候故意出现异常，看第1和第3个语句是否能成功执行。
从上面看出点什么没有，你我执行了三个操作，第一个操作是肯定成功的，第二个是肯定失败的，第三个跟在后面，那么你想一想第一个和第三个操作能插入数据库中吗？我这个程序没有什么意义，但只是未了说明问题。
答案是：不能。
为什么不能，这是SQL所支持的“事务”外完成的，这是技术问题，没有什么的，会了大家都会。为什么要这样做那，那才是要学习的前提。你想一想如果你建立了一个地区的帐物管理系统，当一个单位向另外一个单位转帐的时候，需要执行两个操作就是将一边的信息刷掉，一边的信息添加上去，而当执行一半的时候出现了某种异常中断，比如高优先级的抢占，服务器重起、停电。当时你知道有多少人在访问你的服务器，那要造成多大的数据库信息丢失，甚至于导致数据库的查询的严重失败。那么我就知道需要上面知识的支持了。
3.为什么说上面的东西都很简单那，因为只要你会，那就可以了，而设计方面的东西是永远不是那么简单的，永远带有创新和追求，没有最高的境界。
就一个十分常见的问题，如何在数据库中配合好人员、角色、权限、类别、级别、可操作性这几者的关系，如果是没有经验的人直接上手可能会乱来（我们最早也是这样的）。有经验的人也会设计一段时间，而且随着软件复杂性的增加，其数据库的这几者之间的复杂性就越来越复杂。所以大型软件是非常难的。就一个很简单的例子，在很多的网站中，有上百的栏目信息，而每一个栏目间又保持独立。图片的位置和图片的信息都是动态更新的。某些网站的可操作性都以树型结构提供，而树型结构的子树类别和和叶子都是不重复而不错误。而且其层数都是动态的。有些人给我说可以通过前台的判定语句来执行树型结构的生成，但我问了一个问题，如果是一个邮政编码系统，有几十万个邮政编码你在前台要写多少个case语句，而且每一次要遍历一次已经生成的树，还有用前台的case语句编写出来的树型结构其二级子树全部“定死”，而且树型结构的层树也被定死。这不是完全动态级别的网站。为以后对网站的维护带来麻烦。
总之，数据库是一门入门容易却达到高手很难的学科,通过不断在失败中吸取经验,才能得到一些书籍上无法学会的东西,那才是真正的高手。也就是说，学技术是很快的，要会将技术运用于实际的业务分析，才可以成为一个自我型的DBA，而不是一个简单的程序员。
⑦ 求职简历中"工作实践经历"的撰写能力遵循哪些原则可以凸显出个人能力
“丰富的工作经验”不出意外地成为HR在看简历时最为看重的要素。但现实中，不少求职者会把“工作经验”部分写成“个人编年史”，疏于对信息量进行梳理，导致内容庞杂、缺乏重点，不能突出自己的长项，自然无法引起HR的关注。
能力即卖点，突出重点要突出你具备了解决哪些问题的能力；
事实是证据，少用形容词用事实定义，客观准确地表达你曾经解决了哪些问题；
展示特长，少即是多呈现结果，突出关键字，尤其是和应聘职位要求相符的关键字，不要堆积材料。
写工作经验要有“主线”概念
要有“主线”概念——你是来自什么行业的？从事什么职位？你之前的工作需要你担当哪些职责？每日、每周、每月你要完成哪些工作？……围绕着工作职责和工作内容，你需要阐述自己在过往工作中所积累的经验、技能、知识，以说明你正是用人单位正在寻找的人，你完全能胜任这份工作，除你之外，没人更适合这份工作！
你有什么方法和建议曾被公司、部门或是上司采用过？如有，请简要说明，并用数据进一步说明当这些方法和建议被采纳后，给公司或部门带来里哪些收益，如“实施此项方案后，库存量降低了23%”；
描述你所遇到过的紧急任务或风险管理；
如果你培训过员工，要简要说明培训方法和流程，并用数字进一步说明培训后的效果。
遵循“5W1H”和“PAR”法则
要在简历中突显自己的“卖点”，可采用5W1H（即Who、What、Why、Where、When和How）的写作方式，剖析自己过往的工作经历、工作内容、工作职责。
而要重点说明某一项工作的执行情况时，可采用“PAR”法则，“P”即问题（Problem）、“A”即采取的行动（Action）、“R”即工作的结果和业绩（Result）。从这三方面，你可以用简洁清晰地陈述事件，精炼又到位。而数字和专业术语，会是你的好帮手
用数字说话
用数字来表现工作量、工作效率以及工作成果，会更有说服力和吸引力。滥用形容词，比如“骨干力量”、“进步最快”、“重要贡献”、“成功的方案”、“显着提高”……这些描述性词语并没有说服力。“显着提高”，不如“半年月内将产量提高130%”、“次品率从9%下降为2%”、“节省成本5%”等能给HR留下更深的印象，后者你在面试时也可以进一步阐述。
用专业术语表述
用专业术语，自然是要让自己更显专业。例如，一位求职者在工作经验部分写上“有过分析客户需求的案例”，虽然在这项工作经历中，该求职者并无特别显着的成绩，但还是可以把工作过程中实现目标的方法写出来；如果把这一经历改成“创造和实施了一种全面的需求评估机制，来协助对服务和员工预测的需求”，HR可能会对求职者另眼相看了。
精美word版简历模板可点击我的头像进入我的文库主页；
使用台式电脑可较好的显示简历的设计效果；
http://wenku..com/view/895b49aeaaea998fcd220e16.html
⑧ 简述par原则
PAR原则是在制作简历时的一个原则，P代表problem问题，就是个人背景和工作经历等的总体概述；A代表action行动，及你曾今从事的工作内容等；R代表result结果，也就是说你以前取得的业绩、成功等。
P的部分不是主要的，如果没有什么亮点，可以直接写A的部分。A部分是重点，要写得详细，比如你解决了什么问题，有什么贡献等等，同时要记住强调你个人。最后是R部分，这里你要简洁的话语说清你做的事产生的影响和结果，以及你的贡献和价值。通过PAR原则，你可以把简历中的逻辑理清，使你的简历具体又生动。
⑨ par法则 用数字说话 用专业术语表达
PRA法则是在制作简历时的一个原则。
P代表problem问题，就是个人背景和工作经历等的总体概述。A代表action行动，及你曾今从事的工作内容等，R代表result结果，也就是说你以前取得的业绩、成功等。
⑩ mysql .idb .frm .par是什么文件
【MySQL文件】
MySQL是一个关系型数据库管理系统，由瑞典MySQL AB 公司开发，目前属于 Oracle 旗下公司。MySQL 最流行的关系型数据库管理系统，在 WEB 应用方面MySQL是最好的 RDBMS (Relational Database Management System，关系数据库管理系统)
应用软件之一。MySQL所使用的 SQL 语言是用于访问数据库的最常用标准化语言。
MySQL文件就是SQL文件，里面就是建表语句 以.SQL为后缀。SQL脚本是包含一到多个SQL命令的SQL语句。以将这些SQL脚本放在一个文本文件中(SQL脚本文件)，然后通过相关的命令执行这个SQL脚本文件。
【IDB文件】
IDB智能数据库系统(multimedia intelligent database system)是一个对象数据库管理系统。智能数据库是研究利用人的推理、想象、记忆原理，实现对数据库的存储、搜索和修改。通过有效的组织，能够满足人们快速检索和修改数据库的要求。
IDB文件是一种 MSDev 中间层文件。当IDB文件在IDA打开，数据解压到的文件的集合。后的数据库被关闭时，该文件被压缩回IDB文件。这使得更快的性能，同时在数据库打开和较低的磁盘使用时关闭。
< H1 >其他IDB格式： < /H1 >在调试过程中由一个Visual Studio程序中创建的中间文件，如Visual C， 节省了编译器的状态，并用于最小的重建计划和增量编译。
【PAR文件】
PAR文件为交换文件，主要是Windows环境下的文件名 。绝大多数DOS文件名后缀在Windows下继续有效，但Windows本身也引出了许多种崭新的后缀名，如：*.drv为设备驱动程序(Driver)、*.fon和*.fot都是字库文件、*.grp为分组文件(Group)、*.ini为初始化信息文件 (Initiation)、*.pif为DOS环境下的可执行文件在Windows下执行时所需要的文件格式、*.crd即卡片文件(Card)、*.rec即记录器宏文件(Record)、*.wri即文本文件(Write)，它是字处理write.exe生成的文件、*.doc和*.rtf也是文本文件(Document)，它们是Word产生的文件、*.cal为日历文件、*.clp是剪贴板中的文件格式、*.htm和
*.html即主页文件、*.par为交换文件、*.pwl为口令文件(Password)等等。
【FRM文件】
FRM文件是文本类型文件，用记事本就可以打开，而且也可以保存。
FRM文件扩展名信息：
1.表单;
2.Frame Maker或Frame Builder文档;
3.Oracle可执行表(3.0版或早期版本);
4.Visual Basic表单;
5.WordPerfect Merge表单;
6.DataCAD标志报表文件。