数据库和服务器有什么区别,请解释下

二者的主要区别在于：

服务器：是回应运用软件的总站点，它提供软件的数据收集和处理。服务器通常情况是一台（或台）电脑构成，通过网络与应用软件（客户湍）连接。它硬件珥软件、网络的结合体。

数据库：是存贮信息数据的软件，它有多种。大型的MSSQL，放在服务器上，同时需要数据库软件提供应用 *** 作。小型的放在个体电脑上即可。

扩展资料：

数据库服务器由运行在局域网中的一台/多台计算机和数据库管理系统软件共同构成，数据库服务器为客户应用程序提供数据服务。

数据库服务器建立在数据库系统基础上，具有数据库系统的特性，且有其独特的—面。主要功能如下：

1、数据库管理功能，包括系统配置与管理、数据存取与更新管理、数据完整性管理和数据安全性管理；

2、数据库的查询和 *** 纵功能，该功能包括数据库检索和修改；

3、数据库维护功能，包括数据导入/导出管理，数据库结构维护、数据恢复功能和性能监测；

4、数据库并行运行，由于在同一时间，访问数据库的用户不止一个，所以数据库服务器必须支持并行运行机制，处理多个事件的同时发生。

提问：如何设计或优化千万级别的大表？此外无其他信息，个人觉得这个话题有点范，就只好简单说下该如何做，对于一个存储设计，必须考虑业务特点，收集的信息如下：
1数据的容量：1-3年内会大概多少条数据，每条数据大概多少字节；
2数据项：是否有大字段，那些字段的值是否经常被更新；
3数据查询SQL条件：哪些数据项的列名称经常出现在WHERE、GROUP BY、ORDER BY子句中等；
4数据更新类SQL条件：有多少列经常出现UPDATE或DELETE 的WHERE子句中；
5SQL量的统计比，如：SELECT：UPDATE+DELETE：INSERT=多少？
6预计大表及相关联的SQL，每天总的执行量在何数量级？
7表中的数据：更新为主的业务 还是 查询为主的业务
8打算采用什么数据库物理服务器，以及数据库服务器架构？
9并发如何？
10存储引擎选择InnoDB还是MyISAM？
大致明白以上10个问题，至于如何设计此类的大表，应该什么都清楚了！
至于优化若是指创建好的表，不能变动表结构的话，那建议InnoDB引擎，多利用点内存，减轻磁盘IO负载，因为IO往往是数据库服务器的瓶颈。
另外对优化索引结构去解决性能问题的话，建议优先考虑修改类SQL语句，使他们更快些，不得已只靠索引组织结构的方式，当然此话前提是， 索引已经创建的非常好，若是读为主，可以考虑打开query_cache， 以及调整一些参数值：sort_buffer_size,read_buffer_size,read_rnd_buffer_size,join_buffer_siz。
更多信息参见：
MySQL数据库服务器端核心参数详解和推荐配置
不纸上谈兵，说一下我的思路以及我的解决，抛砖引玉了
我最近正在解决这个问题
我现在的公司有三张表，是5亿的数据，每天张表每天的增量是100w
每张表大概在10个columns左右
下面是我做的测试和对比
1首先看engine,在大数据量情况下，在没有做分区的情况下
mysiam比innodb在只读的情况下，效率要高13％左右
2在做了partition之后，你可以去读一下mysql的官方文档，其实对于partition，专门是对myisam做的优化，对于innodb，所有的数据是存在ibdata里面的，所以即使你可以看到schema变了，其实没有本质的变化
在分区出于同一个physical disk下面的情况下，提升大概只有1％
在分区在不同的physical disk下，我分到了三个不同的disks下，提升大概在3％，其实所谓的吞吐量，由很多因素决定的，比如你的explain parition时候可以看到，record在那一个分区，如果每个分区都有，其实本质上没有解决读的问题，这样只会提升写的效率。
另外一个问题在于，分区，你怎么分，如果一张表，有三个column都是经常被用于做查询条件的，其实是一件很悲惨的事情，因为你没有办法对所有的sql做针对性的分区，如果你只是如mysql官方文档上说的，只对时间做一个分区，而且你也只用时间查询的话，恭喜你
3表主要用来读还是写，其实这个问题是不充分的，应该这样问，你在写入的时候，同时并发的查询多么？我的问题还比较简单，因为mongodb的 shredding支持不能，在crush之后，还是回到mysql，所以在通常情况下，9am－9pm，写入的情况很多，这个时候我会做一个 view，view是基于最近被插入或者经常被查询的，通过做view来分离读取，就是说写是在table上的，读在进行逻辑判断前是在view上 *** 作的
4做一些archive table，比如先对这些大表做很多已有的统计分析，然后通过已有的分析＋增量来解决
5如果你用mysiam，还有一个问题你要注意，如果你的configure的时候，加了一个max index length参数的时候，当你的record数大于制定长度的时候，这个index会被disable

个人的观点，这种大表的优化，不一定上来就要分库分表，因为表一旦被拆分，开发、运维的复杂度会直线上升，而大多数公司是欠缺这种能力的。所以MySQL中几百万甚至小几千万的表，先考虑做单表的优化。

单表优化

单表优化可以从这几个角度出发：

表分区：MySQL在51之后才有的，可以看做是水平拆分，分区表需要在建表的需要加上分区参数，用户需要在建表的时候加上分区参数；分区表底层由多个物理子表组成，但是对于代码来说，分区表是透明的；SQL中的条件中最好能带上分区条件的列，这样可以定位到少量的分区上，否则就会扫描全部分区。

读写分离：最常用的优化手段，写主库读从库；

增加缓存：主要的思想就是减少对数据库的访问，缓存可以在整个架构中的很多地方，比如：数据库本身有就缓存，客户端缓存，数据库访问层对SQL语句的缓存，应用程序内的缓存，第三方缓存（如Redis等）；

字段设计：单表不要有太多字段；VARCHAR的长度尽量只分配真正需要的空间；尽量使用TIMESTAMP而非DATETIME；避免使用NULL，可以通过设置默认值解决。

索引优化：索引不是越多越好，针对性地建立索引，索引会加速查询，但是对新增、修改、删除会造成一定的影响；值域很少的字段不适合建索引；尽量不用UNIQUE，不要设置外键，由程序保证；

SQL优化：尽量使用索引，也要保证不要因为错误的写法导致索引失效；比如：避免前导模糊查询，避免隐式转换，避免等号左边做函数运算，in中的元素不宜过多等等；

NoSQL：有一些场景，可以抛弃MySQL等关系型数据库，拥抱NoSQL；比如：统计类、日志类、弱结构化的数据；事务要求低的场景。

表拆分

数据量进一步增大的时候，就不得不考虑表拆分的问题了：

垂直拆分：垂直拆分的意思就是把一个字段较多的表，拆分成多个字段较少的表；上文中也说过单表的字段不宜过多，如果初期的表结构设计的就很好，就不会有垂直拆分的问题了；一般来说，MySQL单表的字段最好不要超过二三十个。

水平拆分：就是我们常说的分库分表了；分表，解决了单表数据过大的问题，但是毕竟还在同一台数据库服务器上，所以IO、CPU、网络方面的压力，并不会得到彻底的缓解，这个可以通过分库来解决。水平拆分优点很明显，可以利用多台数据库服务器的资源，提高了系统的负载能力；缺点是逻辑会变得复杂，跨节点的数据关联性能差，维护难度大（特别是扩容的时候）。

希望我的回答，能够帮助到你！我将持续分享Java开发、架构设计、程序员职业发展等方面的见解。

分表是分散数据库压力的好方法。

分表，最直白的意思，就是将一个表结构分为多个表，然后，可以再同一个库里，也可以放到不同的库。

当然，首先要知道什么情况下，才需要分表。个人觉得单表记录条数达到百万到千万级别时就要使用分表了。

分表的分类

1、纵向分表

将本来可以在同一个表的内容，人为划分为多个表。（所谓的本来，是指按照关系型数据库的第三范式要求，是应该在同一个表的。）

分表理由：根据数据的活跃度进行分离，（因为不同活跃的数据，处理方式是不同的）

案例：

对于一个博客系统，文章标题，作者，分类，创建时间等，是变化频率慢，查询次数多，而且最好有很好的实时性的数据，我们把它叫做冷数据。而博客的浏览量，回复数等，类似的统计信息，或者别的变化频率比较高的数据，我们把它叫做活跃数据。所以，在进行数据库结构设计的时候，就应该考虑分表，首先是纵向分表的处理。

这样纵向分表后：

首先存储引擎的使用不同，冷数据使用MyIsam 可以有更好的查询数据。活跃数据，可以使用Innodb ,可以有更好的更新速度。

其次，对冷数据进行更多的从库配置，因为更多的 *** 作时查询，这样来加快查询速度。对热数据，可以相对有更多的主库的横向分表处理。

其实，对于一些特殊的活跃数据，也可以考虑使用memcache ,redis之类的缓存，等累计到一定量再去更新数据库。或者mongodb 一类的nosql 数据库，这里只是举例，就先不说这个。

2、横向分表

字面意思，就可以看出来，是把大的表结构，横向切割为同样结构的不同表，如，用户信息表，user_1,user_2等。表结构是完全一样，但是，根据某些特定的规则来划分的表，如根据用户ID来取模划分。

分表理由：根据数据量的规模来划分，保证单表的容量不会太大，从而来保证单表的查询等处理能力。

案例：同上面的例子，博客系统。当博客的量达到很大时候，就应该采取横向分割来降低每个单表的压力，来提升性能。例如博客的冷数据表，假如分为100个表，当同时有100万个用户在浏览时，如果是单表的话，会进行100万次请求，而现在分表后，就可能是每个表进行1万个数据的请求（因为，不可能绝对的平均，只是假设），这样压力就降低了很多很多。

延伸：为什么要分表和分区？

日常开发中我们经常会遇到大表的情况，所谓的大表是指存储了百万级乃至千万级条记录的表。这样的表过于庞大，导致数据库在查询和插入的时候耗时太长，性能低下，如果涉及联合查询的情况，性能会更加糟糕。分表和表分区的目的就是减少数据库的负担，提高数据库的效率，通常点来讲就是提高表的增删改查效率。

什么是分表？

分表是将一个大表按照一定的规则分解成多张具有独立存储空间的实体表，我们可以称为子表，每个表都对应三个文件，MYD数据文件，MYI索引文件，frm表结构文件。这些子表可以分布在同一块磁盘上，也可以在不同的机器上。app读写的时候根据事先定义好的规则得到对应的子表名，然后去 *** 作它。

什么是分区？

分区和分表相似，都是按照规则分解表。不同在于分表将大表分解为若干个独立的实体表，而分区是将数据分段划分在多个位置存放，可以是同一块磁盘也可以在不同的机器。分区后，表面上还是一张表，但数据散列到多个位置了。app读写的时候 *** 作的还是大表名字，db自动去组织分区的数据。

MySQL分表和分区有什么联系呢？

1、都能提高mysql的性高，在高并发状态下都有一个良好的表现。

2、分表和分区不矛盾，可以相互配合的，对于那些大访问量，并且表数据比较多的表，我们可以采取分表和分区结合的方式（如果merge这种分表方式，不能和分区配合的话，可以用其他的分表试），访问量不大，但是表数据很多的表，我们可以采取分区的方式等。

3、分表技术是比较麻烦的，需要手动去创建子表，app服务端读写时候需要计算子表名。采用merge好一些，但也要创建子表和配置子表间的union关系。

4、表分区相对于分表， *** 作方便，不需要创建子表。

我们知道对于大型的互联网应用，数据库单表的数据量可能达到千万甚至上亿级别，同时面临这高并发的压力。Master-Slave结构只能对数据库的读能力进行扩展，写 *** 作还是集中在Master中，Master并不能无限制的挂接Slave库，如果需要对数据库的吞吐能力进行进一步的扩展，可以考虑采用分库分表的策略。

1、分表

在分表之前，首先要选中合适的分表策略（以哪个字典为分表字段，需要将数据分为多少张表），使数据能够均衡的分布在多张表中，并且不影响正常的查询。在企业级应用中，往往使用org_id(组织主键)做为分表字段，在互联网应用中往往是userid。在确定分表策略后，当数据进行存储及查询时，需要确定到哪张表里去查找数据，

数据存放的数据表 = 分表字段的内容 % 分表数量

2、分库

分表能够解决单表数据量过大带来的查询效率下降的问题，但是不能给数据库的并发访问带来质的提升，面对高并发的写访问，当Master无法承担高并发的写入请求时，不管如何扩展Slave服务器，都没有意义了。我们通过对数据库进行拆分，来提高数据库的写入能力，即所谓的分库。分库采用对关键字取模的方式，对数据库进行路由。

数据存放的数据库=分库字段的内容%数据库的数量

3、即分表又分库

数据库分表可以解决单表海量数据的查询性能问题，分库可以解决单台数据库的并发访问压力问题。

当数据库同时面临海量数据存储和高并发访问的时候，需要同时采取分表和分库策略。一般分表分库策略如下：

中间变量 = 关键字%（数据库数量单库数据表数量）

库 = 取整（中间变量/单库数据表数量）

表 = （中间变量%单库数据表数量）

实例：

1、分库分表

很明显，一个主表（也就是很重要的表，例如用户表）无限制的增长势必严重影响性能，分库与分表是一个很不错的解决途径，也就是性能优化途径，现在的案例是我们有一个1000多万条记录的用户表members,查询起来非常之慢，同事的做法是将其散列到100个表中，分别从members0到members99，然后根据mid分发记录到这些表中，牛逼的代码大概是这样子：

复制代码 代码如下:

<php

for($i=0;$i< 100; $i++ ){

//echo "CREATE TABLE db2members{$i} LIKE db1members
";

echo "INSERT INTO members{$i} SELECT FROM members WHERE mid%100={$i}
";

}

>

2、不停机修改mysql表结构

同样还是members表，前期设计的表结构不尽合理，随着数据库不断运行，其冗余数据也是增长巨大，同事使用了下面的方法来处理：

先创建一个临时表：

/创建临时表/

CREATE TABLE members_tmp LIKE members

然后修改members_tmp的表结构为新结构，接着使用上面那个for循环来导出数据，因为1000万的数据一次性导出是不对的，mid是主键，一个区间一个区间的导，基本是一次导出5万条吧，这里略去了

接着重命名将新表替换上去：

/这是个颇为经典的语句哈/

RENAME TABLE members TO members_bak,members_tmp TO members;

就是这样，基本可以做到无损失，无需停机更新表结构，但实际上RENAME期间表是被锁死的，所以选择在线少的时候 *** 作是一个技巧。经过这个 *** 作，使得原先8G多的表，一下子变成了2G多。

摘要 结合DB 的使用经验 从数据库设计 查询优化 并发控制 客户/服务器模式四个方面来讨论数据库应用系统性能优化的一些原则 方法等

关键词 DB 性能优化 数据库设计 查询优化 并发控制 C/S模式

引言

DB 是一种高性能的大型关系数据库管理系统 广泛的应用在客户/服务器体系结构中 评价系统性能优化的标准有 吞吐量 响应时间 并行能力等 本文从数据库的设计 查询的优化 并发控制以及客户/服务器模式这四个角度来讨论优化系统性能

设计数据库

熟悉业务系统

对业务系统的熟悉程度对整个数据库系统的性能有很大影响 一个对业务不熟悉的设计人员 尽管有丰富的数据库知识 也很难设计出性能最佳的数据库应用系统

规范化与非规范化

数据库被规范化后 减少了数据冗余 数据量变小 数据行变窄 这样DB 的每一页可以包括更多行 那么每一区里的数据量更多 从而加速表的扫描 改进了单个表的查询性能 但是 当查询涉及多个表的时候 需要用很多连接 *** 作把信息从各个表中组合在一起 导致更高的CPU和I/O花销 那么 有很多时候需要在规范化和非规范化之间保持平衡 用适当的冗余信息来减少系统开销 用空间代价来换取时间代价 有订单信息表OrderDetail 它里面记录了投递员信息 收款员信息 物品信息 价格策略 客户信息… 这些信息分别在投递员信息表 收款员信息表 物品信息表 价格策略表 客户信息表中存放 如果按照规范化的要求 OrderDetail查询时就必须要与这么多个表进行连接或者嵌套查询 如果OrderDetail表中的数据量是在百万级的 那么一次查询所需要的时间可能会达到好几个小时 事实上 只要在设计时保证数据的逻辑有效性 很多信息都可以直接冗余在OrderDetail表中 这些冗余的数据能够极大的提高查询的效率 从而减少CPU和I/O *** 作

数据条带化

如果一个表的记录条数超过一定的规模 那么最基本的查询 *** 作也会受到影响 需要将该表根据日期水平划分 把最近 最经常用的数据和历史的 不经常用的数据划分开来 或是根据地理位置 部门等等进行划分 还有一种划分方式――垂直划分 即把一个属性列很多的表分割成好几个小表 比如把经常用到的属性放在一个表里 不经常用到的属性放在另一个表里 这样可以加快表的扫描 提高效率

选择数据类型

对每一属性选择什么样的数据类型很大程度上依据表的要求 但是在不违背表要求的前提下 选择适当的数据类型可以提高系统性能 比如有text列存放一本书的信息 用BLOB而不是character( ) BLOB存放的是指针或者文件参照变量 真正的文本信息可以放在数据库之外 从而减少数据库存储空间 使得程序运行的速度提高 DB 提供了UDT（User Defined Datatypes）功能 用户可以根据自己的需要定义自己的数据类型

选择索引

索引是数据库中重要的数据结构 它的根本目的就是为了提高查询效率 现在大多数的数据库产品都采用IBM最先提出的ISAM索引结构 使用索引可以快速 直接 有序的存取数据 索引的建立虽然加快了查询 另一方面却将低了数据更新的速度 因为新数据不仅要增加到表中 也要增加到索引中 另外 索引还需要额外的磁盘空间和维护开销 因此 要合理使用索引

●在经常进行连接 但是没有指定为外键的属性列上建立索引

●在频繁进行排序或分组（即进行group by或order by *** 作）的列上建立索引 按索引来排序或分组 可以提高效率

●在条件表达式中经常用到的不同值较多的列上建立检索 在不同值少的列上不要建立索引

●如果待排序的列有多个 可以在这些列上建立复合索引（pound index） 即索引由多个字段复合而成

查询优化

现在的数据库产品在系统查询优化方面已经做得越来越好 但由于用户提交的SQL语句是系统优化的基础 很难设想一个原本糟糕的查询计划经过系统的优化之后会变得高效 因此用户所写语句的优劣至关重要 下面重点说明改善用户查询计划的解决方案

． 排序

在很多时候 应当简化或避免对大型表进行重复的排序 当能够利用索引自动以适当的次序产生输出时 可以避免排序的步骤 当以下的情况发生时 排序就不能省略

●索引中不包括一个或几个待排序的列

●group by或order by子句中列的次序与索引的次序不一样

●排序的列来自不同的表

为了避免不必要的排序 就要正确地增建索引 合理地合并数据库表 尽管有时可能影响表的规范化 但相对于效率的提高是值得的 如果排序不可避免 那么应当试图简化它 如缩小排序列的范围等

． 主键

主键用整型会极大的提高查询效率 而字符型的比较开销要比整型的比较开销大很多 用字符型数据作主键会使数据插入 更新与查询的效率降低 数据量小的时候这点降低可能不会被注意 可是当数据量大的时候 小的改进也能够提高系统的响应速度

． 嵌套查询

在SQL语言中 一个查询块可以作为另一个查询块中谓词的一个 *** 作数 因此 SQL查询可以层层嵌套 例如在一个大型分布式数据库系统中 有订单表Order 订单信息表OrderDetail 如果需要两表关联查询

SELECT CreateUserFROM Order WHERE OrderNo IN(SELECT OrderNoFROM OrderDetail WHERE Price= )

在这个查询中 找出报纸单价为 元的收订员名单 下层查询返回一组值给上层查询 然后由上层查询块再根据下层块提供的值继续查询 在这种嵌套查询中 对上层查询的每一个值OrderNo 下层查询都要对表OrderDetail进行全部扫描 执行效率显然不会高 在该查询中 有 层嵌套 如果每层都查询 行 那么这个查询就要查询 万行数据 在系统开销中 对表Order的扫描占 ％ 对表OrderDetail的搜索占 ％ 如果我们用连接来代替 即

SELECT CreateUserFROM Order OrderDetailWHERE Order OrderNo=OrderDetail OrderNo AND Praice=

那么对表Order的扫描占 ％ 对表OrderDetail的搜索占 ％

而且 一个列的标签同时在主查询和where子句中的查询中出现 那么很可能当主查询中的列值改变之后 子查询必须重新查询一次 查询嵌套层次越多 效率越低 因此应当尽量避免子查询 如果子查询不可避免 那么要在子查询中过滤掉尽可能多的行

． 通配符

在SQL语句中 LIKE关键字支持通配符匹配 但这种匹配特别耗费时间 例如 SELECT FROM Order WHERE CreateUser LIKE M_ _ _ 即使在CreateUser字段上建立了索引 在这种情况下也还是采用顺序扫描的方式 Order表中有 条记录 就需要比较 次 如果把语句改为SELECT FROM Order WHERE CreateUser > M AND CreateUser < N 在执行查询时就会利用索引来查询 显然会大大提高速度

． distinct

使用distinct是为了保证在结果集中不出现重复值 但是distinct会产生一张工作表 并进行排序来删除重复记录 这会大大增加查询和I/O的 *** 作次数 因此应当避免使用distinct关键字

． 负逻辑

负逻辑如!= <> not in等 都会导致DB 用表扫描来完成查询 当表较大时 会严重影响系统性能 可以用别的 *** 作来代替

． 临时表

使用临时表时数据库会在磁盘中建立相应的数据结构 因为内存的访问速度远远大于外部存储器的访问速度 在复杂查询中使用临时表时 中间结果会被导入到临时表中 这种磁盘 *** 作会大大降低查询效率 另外 在分布式系统中 临时表的使用还会带来多个查询进程之间的同步问题 所以 在进行复杂查询时最好不要使用临时表

． 存储过程

DB 中的Stored Procedure Builder可以产生存储过程 运行并测试存储过程 存储过程可以包含巨大而复杂的查询或SQL *** 作 经过编译后存储在DB 数据库中 用户在多次使用同样的SQL *** 作时 可以先把这些SQL *** 作做成存储过程 在需要用到的地方直接引用其名字进行调用 存储过程在第一次执行时建立优化的查询方案 DB 将查询方案保存在高速缓存里 以后调用运行时可以直接从高速缓存执行 省去了优化和编译的阶段 节省了执行时间 从而提高效率和系统利用率

最优的查询方案按照某些标准选择往往不可行 要根据实际的要求和具体情况 通过比较进行选择 DB 提供的Query Patroller可以对不同的查询方案的查询代价进行比较 通过追踪查询语句 返回查询不同阶段的系统开销 从而作出最佳选择 DB 提供的Performance Monitor也对整个数据库系统的性能进行监控 包括I/O时间 查询次数 排序时间 同步读写时间等等

数据库系统的并发控制也能影响系统性能 多个用户的同时 *** 作可能导致数据的不一致性 DB 为了防止同时修改造成数据丢失和访问未被提交的数据 以及数据的保护读 采用Lock机制来实现控制

lishixinzhi/Article/program/DB2/201311/21921

农业银行总行 年以来正式推广了新版网络版综合业务统计信息系统 该系统是基于WindowsNT 平台 采用客户／服务器模式 以Microsoft SQL Server为基础建立起来的大型数据库应用程序 系统界面友好 *** 作简便 计算 分析 检索功能非常强大 为保证农业银行系统及时进行纵向和横向业务数据采集 按照不同要求生成统计报表 进行全面业务活动分析提供了强有力的保障 但在这套程序的推广 维护中笔者发现系统有时运行速度较慢 特别是在Win 客户端 *** 作时尤为严重 经过排除网线连接等硬件可能带来的影响后上述问题仍然存在 笔者经过仔细摸索 发现系统对硬 软件的要求较高 为充分发挥设计效能 达到最佳运作效果 需要对计算机硬 软件系统进行较为完备的性能测试与最佳配置 特别是内存配置的好坏对系统的运行速度具有决定性的作用 下面 笔者就如何优化SQLServer数据库服务器的内存配置提出一些认识和看法 一 有关内存的基本概念 物理内存与虚拟内存WindowsNT使用两类内存 物理内存与虚拟内存 物理内存 作为RAM芯片安装在计算机内部的存储器 虚拟内存 用于模拟RAM芯片功能的磁盘(硬盘)空间 其实质是通过将内存中当前没有使用的部分内容临时存储到磁盘上 使系统可以使用到比机器物理内存更多的内存 分页和分页文件WindowsNT系统通过使用磁盘空间使得对内存的需求得到部分缓解 从而使用到比物理内存更多内存的技术就称为 交换 或分页 也就是通常所说的虚拟内存技术 通常Windows NT 系统安装时将在引导驱动器上设置一个大小为 MB的交换(分页)文件(pagefile sys) 二 优化Windows NT 系统内存配置在大多数情况下 为了充分发挥Windows NT 系统效能 内存的作用比起处理器的处理能力更具有影响力 特别是在客户／服务器模式环境下更是如此 因为通常在这种环境下并不十分强调处理器的能力 相反却十分注重是否采用足够的内存来满足各个客户的应用需要 此外 为了获得容错功能和保护应用程序 保证应用程序高速运行 充分发挥设计功能都需要有足够多的内存 特别是工业绘图设计和各种工程应用程序更需要占用大量的内存来进行复杂的计算 物理内存(RAM)方便快速的优点显而易见 但由于其价格昂贵 也就不可能做到多多益善了 因此通过合理优化内存配置 扩充虚拟内存提高计算机运算速度也就成了一项很重要的应用技术手段 保证Windows NT系统基本内存需求Windows NT 系统至小应配置 MB内存 MB内存基本够用 正常情况下保证NT系统有 MB内存就可以了 因为并不是所有的 MB基本内存在任何时候都被同时使用 如果添加一些服务和应用程序 则对内存的需求就会急剧增大 如 ( )添加网络服务需要 MB内存空间 ( )容错功能和系统保护功能需要 MB内存(如磁盘镜像和分条功能) ( )进行图形图象处理需要增加 MB内存空间 ( )安装VC VB开发系统需要增加 MB内存空间 另外 如在Windows NT上构建大型数据库如SYBASE Microsoft SQL Server等 对内存的需求就更多了 优化内存性能为了使WindowsNT不至于过分占用较多的内存或者浪费处理器的时间用于换页 可以采用以下方法优化内存性能 ( )减少显示颜色的数量 ( )降低显示分辨率 ( )尽可能不使用或使用位宽度较小的墙纸 ( )关闭不需要的服务程序或驱动程序 尽量不要在服务器上使用其它应用程序 停用服务或驱动程序的 *** 作步骤如下 ①确定需要停用的服务或驱动程序的名称 ②从 控制面板 中双击 服务 或 设备 图标 ③在列表中选择想要停用的服务或设备驱动程序的名称 单击 停止 按钮 这时出现确认 *** 作对话框 ④选择 是 确认 *** 作 然后关闭对话框完成设置 优化虚拟内存在对Windows NT虚拟内存进行设置时需要合理确定各个驱动器分页文件的 起始大小 和 最大值 两个参数 它们用于指定分页文件的起始空间和最大空间 下面对这两个参数作一些解释 起始大小 指初始创建该分页文件时的文件大小 单位为MB 根据缺省设置 这个值被设置为系统中的物理内存的大小 最大值 指出该分页文件的最大尺寸 单位为MB ( )分页文件的设置原则 ①分页文件起始大小应保留缺省设置 一般情况下请不要改动 ②分页文件理想的最大尺寸为系统物理内存尺寸的 倍至 倍 需要说明的是 如果系统工作时不需要大量内存 请选择靠近下限的值 即用系统物理内存的 倍作为这个尺寸的起始值 如果系统工作时需要大量内存 请选择靠近上限的值 ( )Windows NT虚拟内存设置步骤 ①从 控制面板 中双击 系统 图标 ②在 系统特性 对话框中单击 性能 标签 ③在虚拟内存对话框中单击 更改 按钮 这时出现 虚拟内存 对话框 上端的驱动器框逐一列出了 Windows NT所有页面文件的大小 ④在驱动器列表中 选择需要设置分页文件的驱动器盘符 在 驱动器页面文件大小 对话框中列出了 起始大小 和 最大值 两个参数栏 填入按照上面的原则确定的数值 ⑤单击 设置 确认以上 *** 作 然后依次单击 确定 按钮退出各个对话框 完成设置 ( )Win ／ 虚拟内存设置 Win ／ 虚拟内存设置方法 步骤和原则与Windows NT 的设置大致相同 请参照上面Windows NT的设置 注意事项( )合理确定分页文件的最大值 根据系统需求随时进行调整 使用过多虚拟内存将导致整个系统处理性能的下降 设置虚拟内存最大值的目的是使用户不必在WindowsNT的交换文件上消耗过多的磁盘空间 通常情况下如果超过了系统需要的最佳值后 生成交换文件的磁盘空间就被浪费了 ( )尽可能设立专用硬盘配置内存交换区 或将交换空间放到主硬盘的另一个分区 同时应将主硬盘的交换文件大小降至 MB 这样主硬盘(分区)仅用来放置 *** 作系统和应用程序 就可以减少交换次数 防止频繁交换耗费大量 CPU时间 ( )虚拟内存技术的确改善了Windows NT系统的性能 但也受到机器硬盘空间大小 硬盘速度 处理器 (CPU)速度的影响 从理想角度出发 要提高计算机的性能就必须减少交换 *** 作的次数 但是没有一个WindowsNT计算机不发生交换 这就要求计算机要有足够的物理内存 以保持最少的交换 *** 作 三 优化Microsoft SQL Server数据库内存配置内存是影响Microsoft SQL Server系统性能的一个重要因素 SQL Server数据库安装时将为具有 MB物理内存的机器缺省配置 MB可用内存 MB物理内存的机器缺省配置 MB可用内存 应在Microsoft SQL Server数据库安装后进行内存选项(Memory)设置 最大配置值为 GB 为了确定SQL Server系统最适宜的内存需求 可以从总的物理内存中减去Windows NT 需要的内存以及其它一些内存需求后综合确定 理想的情况是给SQL Server分配尽可能多的内存 而不产生页面调度 根据物理内存合理规划SQL Server可用内存在大多数的生产环境中 服务器配备的物理内存是 MB～ MB 偶尔也有 MB的 只要配置恰当是完全可以满足SQL Server的内存需求的 下表是笔者关于SQL Server内存分配的建议规划 供参考 物理内存 分配给SQL Server 设置值(单位 KB) MB MB MB MB MB ～ MB ～ MB ～ MB ～ MB ～ MB ～ MB ～ MB ～ MB ～ MB ～ MB ～ MB ～ 以下是SQL Server内存选项(Memory)设置方法( )从Microsoft SQL Server程序集中启动SQL Enterprise Manager ( )从Server Manager窗口中选择 Server 菜单选项 ( )在 Server 菜单中选择 Configurations 选项 ( )在 Server Configuration 对话框中选择 Configuration 标签 Configuration窗口显示配置选项列表 ( )选中 Memory 项目 在 Current 栏填入新值 ( )停止并重新启动SQLServer服务 使设置生效 合理扩充虚拟内存 增大SQL Server可用内存当SQL Server系统确实需要扩大可用内存时 应在磁盘空间充足的情况下扩充供虚拟内存 并相应增大 SQL Server可用内存 具体做法是 系统管理员首先扩充服务器的虚拟内存 然后再参考上表增大SQL Server可用内存 关键是要根据系统的负载情况综合决定是否扩充内存 优化配置 使用tempinRAMSQL Server使用tempdb临时数据库作为一些查询连接 *** 作时排序或创建临时表的工作空间 将tempdb创建在RAM中可以使系统 *** 作性能有较大提高 而且因为tempdb在每次重启动服务器时都重建 这样即使有非正常的关闭也是较为安全的 例如停电故障 要将tempdb创建在RAM中 可以使用sp_configure进行设置 具体用法请参阅有关资料 由于tempdbinRAM使用的内存是由系统从内存体单独分配的 与SQL Server的内存选项设置的可用内存池是分开的 使用tempdbin RAM将减少整个系统的可用内存 应根据SQL Server和服务器运行情况进行配置 否则就可能适得其反 影响系统性能 另外 适当增加tempdb数据库空间 即使不使用temp lishixinzhi/Article/program/SQLServer/201311/22052

如果你有高访问量的网站，可以考虑优化MySQL数据库，以提高性能和流畅度。以下是一些优化MySQL数据库的方法：1 使用索引：索引可以帮助查询过程更快地检索数据。尽量使用单列索引而不是复合索引，因为复合索引增加了查询的复杂度。2 使用缓存：使用缓存可以减少数据库的访问次数，提高查询速度。可以使用内存缓存或外部缓存，例如Memcached。3 优化查询：优化查询可以减少数据库的负担，提高查询速度。可以使用EXPLN来分析查询语句的执行计划，并对语句进行优化。4 使用合适的数据类型：使用合适的数据类型可以减少存储空间和读取时间，提高查询速度。例如，使用整数类型代替字符串类型存储数字数据。5 定期清理数据：定期清理数据可以减少数据库的负担，提高查询速度。可以使用定时任务或脚本自动清理数据。6 配置合适的数据库服务器：使用合适的数据库服务器可以提高数据库性能和稳定性。例如，使用高性能的硬件和网络设备。7 避免使用SQL语句的通配符：通配符可以匹配所有符合条件的数据，但是会增加查询的复杂度和执行时间。尽量避免在查询语句中使用通配符。

---