SQL Server 与 MySQL 性能相差多大

MySQL和SQLServer的比较

对于程序开发人员而言，目前使用最流行的两种后台数据库即为MySQL和SQLServer。这两者最基本的相似之处在于数据存储和属于查询系统。你可以使用sql来访问这两种数据库的数据，因为它们都支持ansi-sql。 还有，这两种数据库系统都支持二进制关键词和关键索引，这就大大地加快了查询速度。同时，二者也都提供支持xml的各种格式。除了在显而易见的软件价格上的区别之外，这两个产品还有什么明显的区别吗？在这二者之间你是如何选择的？让我们看看这两个产品的主要的不同之处，包括发行费用，性能以及它们的安全性。

根本的区别是它们遵循的基本原则

二者所遵循的基本原则是它们的主要区别：开放vs保守。SQLServer服务器的狭隘的，保守的存储引擎与MySQL服务器的可扩展，开放的存储引擎绝然不同。虽然你可以使用SQLServer服务器的sybase引擎，但MySQL能够提供更多种的选择，如myisam, heap, innodb, and berkeley db。MySQL不完全支持陌生的关键词，所以它比SQLServer服务器要少一些相关的数据库。同时，MySQL也缺乏一些存储程序的功能，比如myisam引擎联支持交换功能。

发行费用：MySQL不全是免费，但很便宜

当提及发行的费用，这两个产品采用两种绝然不同的决策。对于SQLServer服务器，获取一个免费的开发费用最常的方式是购买微软的office或者visual studio的费用。但是，如果你想用于商业产品的开发，你必须还要购买sql server standard edition。学校或非赢利的企业可以不考虑这一附加的费用。

性能：先进的MySQL

纯粹就性能而言，MySQL是相当出色的，因为它包含一个缺省桌面格式myisam。myisam 数据库与磁盘非常地兼容而不占用过多的cpu和内存。MySQL可以运行于windows系统而不会发生冲突，在unix或类似unix系统上运行则更好。你还可以通过使用64位处理器来获取额外的一些性能。因为MySQL在内部里很多时候都使用64位的整数处理。Yahoo!商业网站就使用MySQL作为后台数据库。

当提及软件的性能，SQLServer服务器的稳定性要比它的竞争对手强很多。但是，这些特性也要付出代价的。比如，必须增加额外复杂操作，磁盘存储，内存损耗等等。如果你的硬件和软件不能充分支持SQLServer服务器，我建议你最好选择其他如dbms数据库，因为这样你会得到更好的结果。

安全功能

MySQL有一个用于改变数据的二进制日志。因为它是二进制，这一日志能够快速地从主机上复制数据到客户机上。即使服务器崩溃，这一二进制日志也会保持完整，而且复制的部分也不会受到损坏。

在SQLServer服务器中，你也可以记录SQLServer的有关查询，但这需要付出很高的代价。

安全性

这两个产品都有自己完整的安全机制。只要你遵循这些安全机制，一般程序都不会出现什么问题。这两者都使用缺省的ip端口，但是有时候很不幸，这些ip也会被一些黑客闯入。当然，你也可以自己设置这些ip端口。

恢复性:先进的sql服务器

恢复性也是MySQL的一个特点，这主要表现在myisam配置中。这种方式有它固有的缺欠，如果你不慎损坏数据库，结果可能会导致所有的数据丢失。然而，对于SQLServer服务器而言就表现得很稳键。SQLServer服务器能够时刻监测数据交换点并能够把数据库损坏的过程保存下来。

根据需要决定你的选择

对于这两种数据库，如果非要让我说出到底哪一种更加出色，也许我会让你失望。以我的观点，任一对你的工作有帮助的数据库都是很好的数据库，没有哪一个数据库是绝对的出色，也没有哪一个数据库是绝对的差劲。我想要告诉你的是你应该多从你自己的需要出发，即你要完成什么样的任务？而不要单纯地从软件的功能出发。

如果你想建立一个net服务器体系，这一体系可以从多个不同平台访问数据，参与数据库的管理，那么你可以选用SQLServer服务器。如果你想建立一个第三方站点，这一站点可以从一些客户端读取数据，那么MySQL将是最好的选择。　

这两者数据库都能够在net或j2ee下运行正常，同样，都能够利用raid。

关于数据库优化，网上有不少资料和方法，但是不少质量参差不齐，有些总结的不够到位，内容冗杂。偶尔发现了这篇文章，很经典，文章流量也很大，希望对大家今后开发中也有帮助

1、选取最适用的字段属性

MySQL可以很好的支持大数据量的存取，但是一般说来，数据库中的表越小，在它上面执行的查询也就会越快。因此，在创建表的时候，为了获得更好的性能，我们可以将表中字段的宽度设得尽可能小。

例如，在定义邮政编码这个字段时，如果将其设置为CHAR(255),显然给数据库增加了不必要的空间，甚至使用VARCHAR这种类型也是多余的，因为CHAR(6)就可以很好的完成任务了。同样的，如果可以的话，我们应该使用MEDIUMINT而不是BIGIN来定义整型字段。

另外一个提高效率的方法是在可能的情况下，应该尽量把字段设置为NOT NULL，这样在将来执行查询的时候，数据库不用去比较NULL值。

对于某些文本字段，例如“省份”或者“性别”，我们可以将它们定义为ENUM类型。因为在MySQL中，ENUM类型被当作数值型数据来处理，而数值型数据被处理起来的速度要比文本类型快得多。这样，我们又可以提高数据库的性能。

2、使用连接（JOIN）来代替子查询(Sub-Queries)

MySQL从41开始支持SQL的子查询。这个技术可以使用SELECT语句来创建一个单列的查询结果，然后把这个结果作为过滤条件用在另一个查询中。例如，我们要将客户基本信息表中没有任何订单的客户删除掉，就可以利用子查询先从销售信息表中将所有发出订单的客户ID取出来，然后将结果传递给主查询，如下所示：

DELETE FROM customerinfo

WHERE CustomerID NOT in (SELECT customerid FROM salesinfo)使用子查询可以一次性的完成很多逻辑上需要多个步骤才能完成的SQL操作，同时也可以避免事务或者表锁死，并且写起来也很容易。但是，有些情况下，子查询可以被更有效率的连接（JOIN）替代。例如，假设我们要将所有没有订单记录的用户取出来，可以用下面这个查询完成：

SELECT FROM customerinfo

WHERE customerid NOT IN (SELECT customerid FROM salesinfo)如果使用连接（JOIN）来完成这个查询工作，速度将会快很多。尤其是当salesinfo表中对CustomerID建有索引的话，性能将会更好，查询如下：

SELECT FROM customerinfo

LEFT JOIN salesinfo ON customerinfocustomerid =salesinfocustomerid

WHERE salesinfocustomerid IS NULL连接（JOIN）之所以更有效率一些，是因为MySQL不需要在内存中创建临时表来完成这个逻辑上的需要两个步骤的查询工作。

3、使用联合(UNION)来代替手动创建的临时表

MySQL从40的版本开始支持union查询，它可以把需要使用临时表的两条或更多的select查询合并的一个查询中。在客户端的查询会话结束的时候，临时表会被自动删除，从而保证数据库整齐、高效。使用union来创建查询的时候，我们只需要用UNION作为关键字把多个select语句连接起来就可以了，要注意的是所有select语句中的字段数目要想同。下面的例子就演示了一个使用UNION的查询。

SELECT name,phone FROM client UNION

SELECT name,birthdate FROM author UNION

SELECT name,supplier FROM product4、事务

尽管我们可以使用子查询（Sub-Queries）、连接（JOIN）和联合（UNION）来创建各种各样的查询，但不是所有的数据库操作都可以只用一条或少数几条SQL语句就可以完成的。更多的时候是需要用到一系列的语句来完成某种工作。但是在这种情况下，当这个语句块中的某一条语句运行出错的时候，整个语句块的操作就会变得不确定起来。设想一下，要把某个数据同时插入两个相关联的表中，可能会出现这样的情况：第一个表中成功更新后，数据库突然出现意外状况，造成第二个表中的操作没有完成，这样，就会造成数据的不完整，甚至会破坏数据库中的数据。要避免这种情况，就应该使用事务，它的作用是：要么语句块中每条语句都操作成功，要么都失败。换句话说，就是可以保持数据库中数据的一致性和完整性。事物以BEGIN关键字开始，COMMIT关键字结束。在这之间的一条SQL操作失败，那么，ROLLBACK命令就可以把数据库恢复到BEGIN开始之前的状态。

BEGIN;

INSERT INTO salesinfo SET customerid=14;

UPDATE inventory SET quantity =11 WHERE item='book';

COMMIT;事务的另一个重要作用是当多个用户同时使用相同的数据源时，它可以利用锁定数据库的方法来为用户提供一种安全的访问方式，这样可以保证用户的操作不被其它的用户所干扰。

5、锁定表

尽管事务是维护数据库完整性的一个非常好的方法，但却因为它的独占性，有时会影响数据库的性能，尤其是在很大的应用系统中。由于在事务执行的过程中，数据库将会被锁定，因此其它的用户请求只能暂时等待直到该事务结束。如果一个数据库系统只有少数几个用户来使用，事务造成的影响不会成为一个太大的问题；但假设有成千上万的用户同时访问一个数据库系统，例如访问一个电子商务网站，就会产生比较严重的响应延迟。

其实，有些情况下我们可以通过锁定表的方法来获得更好的性能。下面的例子就用锁定表的方法来完成前面一个例子中事务的功能。

LOCK TABLE inventory WRITE SELECT quantity FROM inventory WHERE Item='book';

UPDATE inventory SET Quantity=11 WHERE Item='book';UNLOCKTABLES这里，我们用一个select语句取出初始数据，通过一些计算，用update语句将新值更新到表中。包含有WRITE关键字的LOCKTABLE语句可以保证在UNLOCKTABLES命令被执行之前，不会有其它的访问来对inventory进行插入、更新或者删除的操作。

6、使用外键

锁定表的方法可以维护数据的完整性，但是它却不能保证数据的关联性。这个时候我们就可以使用外键。

例如，外键可以保证每一条销售记录都指向某一个存在的客户。在这里，外键可以把customerinfo表中的customerid映射到salesinfo表中customerid，任何一条没有合法customerid的记录都不会被更新或插入到salesinfo中。

CREATE TABLE customerinfo( customerid int primary key) engine = innodb;

CREATE TABLE salesinfo( salesid int not null,customerid int not null, primary key(customerid,salesid),foreign key(customerid) references customerinfo(customerid) on delete cascade)engine = innodb;注意例子中的参数“on delete cascade”。该参数保证当customerinfo表中的一条客户记录被删除的时候，salesinfo表中所有与该客户相关的记录也会被自动删除。如果要在MySQL中使用外键，一定要记住在创建表的时候将表的类型定义为事务安全表InnoDB类型。该类型不是MySQL表的默认类型。定义的方法是在CREATE TABLE语句中加上engine=INNODB。如例中所示。

7、使用索引

索引是提高数据库性能的常用方法，它可以令数据库服务器以比没有索引快得多的速度检索特定的行，尤其是在查询语句当中包含有MAX(),MIN()和ORDERBY这些命令的时候，性能提高更为明显。

那该对哪些字段建立索引呢？

一般说来，索引应建立在那些将用于JOIN,WHERE判断和ORDERBY排序的字段上。尽量不要对数据库中某个含有大量重复的值的字段建立索引。对于一个ENUM类型的字段来说，出现大量重复值是很有可能的情况

例如customerinfo中的“province”字段，在这样的字段上建立索引将不会有什么帮助；相反，还有可能降低数据库的性能。我们在创建表的时候可以同时创建合适的索引，也可以使用ALTERTABLE或CREATEINDEX在以后创建索引。此外，MySQL从版本32323开始支持全文索引和搜索。全文索引在MySQL中是一个FULLTEXT类型索引，但仅能用于MyISAM类型的表。对于一个大的数据库，将数据装载到一个没有FULLTEXT索引的表中，然后再使用ALTERTABLE或CREATEINDEX创建索引，将是非常快的。但如果将数据装载到一个已经有FULLTEXT索引的表中，执行过程将会非常慢。

8、优化的查询语句

绝大多数情况下，使用索引可以提高查询的速度，但如果SQL语句使用不恰当的话，索引将无法发挥它应有的作用。

下面是应该注意的几个方面。

a、 首先，最好是在相同类型的字段间进行比较的操作

在MySQL323版之前，这甚至是一个必须的条件。例如不能将一个建有索引的INT字段和BIGINT字段进行比较；但是作为特殊的情况，在CHAR类型的字段和VARCHAR类型字段的字段大小相同的时候，可以将它们进行比较。

b、 其次，在建有索引的字段上尽量不要使用函数进行操作

例如，在一个DATE类型的字段上使用YEAE()函数时，将会使索引不能发挥应有的作用。所以，下面的两个查询虽然返回的结果一样，但后者要比前者快得多。

c、第三，在搜索字符型字段时，我们有时会使用LIKE关键字和通配符，这种做法虽然简单，但却也是以牺牲系统性能为代价的

例如下面的查询将会比较表中的每一条记录。

SELECT FROM books WHERE name like "MySQL%"但是如果换用下面的查询，返回的结果一样，但速度就要快上很多：

SELECT FROM books WHERE name ＞= "MySQL" and name ＜"MySQM"最后，应该注意避免在查询中让MySQL进行自动类型转换，因为转换过程也会使索引变得不起作用。

SQL Server数据库与Windows操作系统来自同一个家庭，在技术上具有一定的共通性。我们可以调整Windows操作系统的一些参数来提高SQLServer数据库服务器的性能，使之更高效的运行。

一、 提高虚拟内存来提高数据库服务器性能。

虚拟内存简单的来说就是内盘中的一块空间。当物理内存不够时，操作系统会自动把某些驻留在内存中暂时不用的内容移植到这个在硬盘上的虚拟内存中，以释放更多的空间给新的应用程序使用。也就是说，当物理内存使用完时操作系统会拿出一部分硬盘空间来充当内存使用，以缓解内存的压力。为此从某种程度来说，这个虚拟内存的设置也会影响到数据库服务器的性能。那么这个虚拟内存到底该设置多少为好呢这没有一个固定的标准。这需要数据库管理员根据部署的应用来确定。

如数据库没有一些高级的应用，如数据仓库、全文索引或者不适多个应用服务一身的话，笔者认为只要把虚拟内存设置为物理内存的15倍即可。但是，如果在数据库服务器上配置了数据仓库或者全文索引的话，则这个15倍的虚拟内存往往是不够的。此时笔者建议需要把虚拟内存配置为物理内存的3倍到四倍。同时，需要调整数据库中的最大服务器内存选项，将其设置为物理内存的15倍。也就是说，其在使用内存的时候，可以使用虚拟内存大小的一半。注意这个设置时必须的，否则的话，调整数据库虚拟内存很难起到应有的效果。而且当以后内存升级了，则也需要同时更改这个两个参数。

最后需要说明的一点就是，虚拟内存并不是越大越好。如果设置为10倍、20倍，那么这是浪费。以往内存中没有这么多的内容可以往虚拟内存中存放。所以，针对SQL Server数据库与Windows服务器来说，4倍于物理内存的虚拟内存已经足够了。设置的再大的话，就没有多少的实际意义了。

二、 调整本地客户端的任务优先级。

在数据库初始化的过程中，有大部分的任务需要在本地客户端上完成。即时在后续维护中，出于某种原因仍然要在本地客户端上操作。那么什么是本地客户端呢其实本地客户端就是跟数据库服务器部署在同一台计算机上的客户端。如我们在导入期初数据的时候，为了方便会在本地客户端上直接进行操作。因为这可以节省数据在网络上传输的时间。

不过在本地客户端上进行操作的时候，往往分为前台运行与后台运行。操作系统这么设计的本意是为了提高远程客户端的执行效率。如在远程客户端生成物料需求计划的时候，由于运算量比较大，其花费的时间可能比较久，如可能需要20分钟。为了提高工作效率，对于类似的作业，应用程序可以把这个运算放置在后台运行。不过需要注意的是，把某个作业放置在后台运行，并不能够节省其运行的时间，而往往由于放置在后台的作业其优先级比较低，往往实际花费的时间还会延长，如会延长到23分钟等等。之所以要把这个长时间运行的作业放置在后台，主要是为了让用户不用干等，可以先作其他事情。等到运行完成后，系统会自动把相关的结果返回给用户。这在感觉上是缩短了运行的时间(往往在等待的过程中时间过得特别慢)，而实际上其运行的时间根本没有缩短，甚至会更长。

这个处理策略对于远程客户端来说确实有用，至少可以在感觉上缩短用户的等待时间。而且可以让用户先进行其他的操作。但是如果在本地客户端上，处理某些作业的时候，可能并不希望如此。如在本地客户度进行物料需求计划测试，数据库管理员希望即时把这个计划放置在后台运行，其也能够与前台应用程序具有相同的优先级，以减少这个处理时间。所以，当数据库管理员遇到类似情况时，就需要调整操作系统的相关设置，让作为在后台运行的应用程序，也能够与前台运行的其他应用程序具有相同的优先级。

通常情况下，安装完干净的SQL Server数据库时，服务器任务调度设置为“务”，即前后台应用程序没有优先级的分别。也就是说，此时将为前台应用程序与后台应用程序提供相等的处理时间。但是有时候为了兼顾远程客户端，在部署实例的时候，会改变这设置。如把降低后台应用程序的优先级，让更多的资源能够服务于前台应用程序。在大部分情况下，这个设置是必要的。不过如果出于某些原因需要在本地客户端执行某些操作的话，则数据库管理员需要暂时调整这个配置，以节省某些作业的运行时间。有时候甚至可以将服务器任务调度设置为最大或者应用程序，这就可以为前台应用程序提高最大的处理器时间。

可见，任务调度计划设置也没有一个统一的优劣标准。主要还是需要看数据库服务器到底用来做什么为此这也对数据库管理员提出了比较高的要求。此时数据库管理员必须要理解各种优先级设置对于数据库服务器性能的影响。然后再根据当时的实际应用来合理的调整任务级别的优先级，以取得本地客户端操作的最大性能。

三、 限制系统内存用户文件缓存的大小。

毋庸置疑，数据库服务器的物理内存对于数据库的性能具有至关重要的影响。但是有时候我们会发现一个奇怪的现象，即即时增加了数据库服务器的物理内存，但是仍然没有发现数据库的性能有很大的改善，或则说比原先的还要差一点。这是什么原因呢如结合SQLServer数据库来说，这主要是内存的分配不是很合理。如大部分的内存被用来存放文件缓存。此时如果增加的内存都被用来存放文件缓存了，那么光靠简单的增加内存并不能够提高数据库的性能。所以，有时候我们数据库管理员需要优化SQL Server服务器的内存使用情况，如需要限制用户文件缓存的内存量。

那么该如何限制呢这不是SQLServer数据库服务器来完成的，而是需要通过Windows操作下系统的配置来实现。如要限制文件系统缓存，需要确保没有选择“最大化文件共享数据吞吐量”这个选项(其原来是为文件共享所准备的)，然后选择“最小化使用对内存”或者“平衡”选项，来制定最小文件系统缓存。

具体来说，可以按如下步骤来调整这个选项，以提高服务器的性能。首先，依次打开控制面板、选择网络连接、单击本地连接。然后打开常规选项卡，选择属性。在本地连接属性对话框中选择常规选项卡，选择微软网络的文件和打印机共享，并单击属性。在弹出来的对话框中，去掉“最大化文件共享数据吞吐量”选择，可以选择“最大化网络应用程序的数据吞吐量”。然后按确定即可。如此操作系统就会自动调整内存的分配，不会给文件缓存保留很大的空间，从而可以提高数据库内部处理的性能。往往这对于事务性的应用系统很有作用，能够在很大程度上提高数据库的性能。

不过在调整这个配置后，如果在站台服务器上还部署有文件服务器的话，那么这个文件服务器的性能就会受到比较大的影响。因为对于文件服务器应用来说，需要比较大的文件缓存量。为此在某种程度上来说，数据库服务器与文件服务器在这方面是相互冲突的。数据库管理员就需要相互权衡，然后确定一个最佳的处理方案。不过一般情况下，不建议将数据库服务器与文件服务器、打印服务器等等部署在同一个服务器上。因为这三种不同的应用，彼此之间的资源争用还是很厉害的。为此会给数据库的性能带来比较大的负面影响。

如果光从数据库服务器来说，限制文件缓存的内存使用量，确实可以提高数据库服务器的性能。特别是对于某些特别的应用与计算，由于需要用到比较大的内存，故可以大幅度提高这些作业的运算量。

可见我们在优化数据库性能的时候，有时还不能够光从数据库服务器着手。必要的时候，我们需要换一个角度，从操作系统出发，调整操作系统的相关配置，也能够明显的提高数据库的性能。