周杰伦的所有歌曲中，我最喜欢的歌就是《听妈妈的话》，其中有这么一句歌词：小朋友，你是否有很多问号，为什么别人在那看漫画，我却在学画画。
应用在现在的场景就是：小伙伴，你是否有很多问号，为什么别人只需要简单用一下MySQL，你却要对MySQL深入浅出。
实际上每天的进步都是为了自己能接受顶尖大佬的技术熏陶，虽然我们不能亲自聆听他们的声音，但是他们已经将自己的思路写在了他们的开源项目里，这就是我们学习开源项目的意义所在。
比如今天，我们的话题是：MySQL可以存储上亿级别的数据，但是却几乎不会丢失数据，这里面到底是因为什么？
先给出结论：MySQL的数据不丢失就需要保证binlog和redo log都持久化到磁盘，因此，为了保证数据不丢失，就需要了解两个日志的写入机制。
1 binlog写入机制
1.1 写入原则
binlog的写入逻辑为：事务执行过程中，先把日志写到binlog cache，事务提交的时候，再把binlog cache写到binlog文件中。
同时，一个事务的Binlog是不能拆开的，因此，无论事务多大，也要确保一次性写入，这就涉及到binlog cache的保存问题。原因在于：binlog写入的前提条件是事务被提交，事务至少进入prepare状态，若此时一个事务的binlog拆分写，意味着备库执行时，可能将还没有提交的事务执行，导致主备数据不一致。
系统给binlog cache分配了一块内存，每个线程一个，参数binlog_cache_size用于控制单个线程内binlog cache所占内存大小。如果超过了这个参数规定大小，就要暂存到磁盘。可以通过语句sHow status like ‘Binlog_cache_disk_use’;判断默认大小32KB是否满足大小，如果语句的值远大于0，需要增加binlog_cache_size的值；
事务提交时，执行器把binlog cache里的完整事务写入到binlog，并清空binlog cache。实际上，在第一段提交状态变为prepare状态时，就可以把binlog cache写入binlog，因此，即使之后crash，也能恢复数据。
1.2 写入流程
如图所示，每个线程有自己binlog cache，但是共用同一份binlog文件。执行流程为：
Page Cache是OS关于磁盘IO的缓存，位于内核中，不适用于大文件传输，因为大文件传输page cache的命中率比较低，这个时候page cache不仅没有起到作用还增加了一次数据从磁盘buffer到内核page cache的开销；
高版本的Linux系统中已经把Buffer跟虚拟文件系统的page cache合并在一起了，因此也就没有从磁盘buffer拷贝到内核page cache的开销；
write和fsync的时机，由参数sync_binlog控制（与redis的appendfsync相似）：
因此，在出现 IO 瓶颈的场景里，将 sync_binlog 设置成一个比较大的值，可以提升性能。在实际的业务场景中，考虑到丢失日志量的可控性，一般不建议将这个参数设成 0，比较常见的是将其设置为 100~1000 中的某个数值。
但是，将 sync_binlog 设置为 N，对应的风险是：如果主机发生异常重启，会丢失最近 N 个事务的 binlog 日志。
2 redo log机制
2.1 redo log三种状态
如图所示的三种颜色就是redo log的三种状态：
fsync函数同步内存中所有已修改的文件数据到储存设备。一般情况下，对硬盘（或者其他持久存储设备）文件的write操作，更新的只是内存中的页缓存（page cache），而脏页面不会立即更新到硬盘中，而是由操作系统统一调度，如由专门的flusher内核线程在满足一定条件时（如一定时间间隔、内存中的脏页达到一定比例）内将脏页面同步到硬盘上（放入设备的IO请求队列）。 因为write调用不会等到硬盘IO完成之后才返回，因此如果OS在write调用之后、硬盘同步之前崩溃，则数据可能丢失。
如果事务执行过程中MySQL发生异常重启，这部分日志丢了，也不会有损失，因为事务还没有提交， 因此，redo log buffer不需要每次生成都直接持久化磁盘。
2.2 redo log写入策略
由于都是内存操作，因此日志写入redo log buffer，以及write到page cache都很快，但是持久化磁盘的速度比较慢。
为控制写入策略，InnoDB提供了innodb_flush_log_at_trx_commit参数：
2.3 刷盘时机
1）定时任务：InnoDB有一个后台线程，每隔1秒，就会把redo log buffer日志调用write写入到文件系统的page cache，然后调用fsync持久化到磁盘。
事务执行过程中的redo log也是直接写入到buffer中，这些redo log也会被后台线程一起持久化到磁盘，因此，一个没有提交的事务的redo log也可能已经持久化到磁盘。
2）空间不足：redo log buffer占用的空间即将到达innodb_log_buffer_size一半时，后台线程会主动写盘。注意，此时由于这个事务还没有提交，所以这个写盘动作只是write，没有调用fsync，即：只是写入到page cache中。
3）其他事务提交：并行事务提交时，顺带将这个事务的redo log buffer持久化到磁盘。假设一个事务 A 执行到一半，已经写了一些 redo log 到 buffer 中，这时候有另外一个线程的事务 B 提交，如果 innodb_flush_log_at_trx_commit 设置的是 1，那么按照这个参数的逻辑，事务 B 要把 redo log buffer 里的日志全部持久化到磁盘。这时候，就会带上事务 A 在 redo log buffer 里的日志一起持久化到磁盘。
2.4 配置说明
两阶段提交，时序上是redo log先prepare，再写binlog，最后再把redo log commit。
如果把innodb_flush_log_at_trx_commit设置为1，那么redo log在prepare阶段就要持久化一次，因为crash-safe依赖于prepare状态的redo log + binlog恢复。
每秒一次后台轮询刷盘，再加上crash-safe，InnoDB认为redo log在commit时只需要write到文件系统的page cache就可以了，因为只要binlog写盘成功，就算redo log状态还是prepare状态也会被认为事务已经执行成功，所以只需要write到page cache就OK了，没必要浪费IO主动执行一次fsync。
MySQL的“双1”配置，指的就是sync_binlog和innodb_flush_log_at_trx_commit设置为1.即：一个事务完整提交前，需要等待两次刷盘，一次是redo log的prepare阶段，一个是Binlog。
这里需要注意的是，在事务中有两次commit，第一次commit是事务语句的commit，这里说的commit主要是第二次commit，即：redo log的commit。
两个commit的不是一个东西，在事务提交时，commit语句可以称为commit1, 这时就会将redolog和 binlog fsync到磁盘, 这里写入的redolog是prepare状态（此时是语句的commit事务），如果这个prepare状态的redolog和binlog都fsync成功的话，这个数据就不会丢失了。 然后后续把redolog的状态从prepare的状态变成commit状态，这里称为commit2，这里的改变状态是后台线程刷的，和数据不丢就没啥关系，只是为了让redolog状态完整。
2.5 组提交（group commit）
LSN(Log Sequence Number，日志逻辑序列号）是单调递增的，用来对应redo log的一个个写入点，每次写入长度为length的redo log，LSN的值就会加上length。
LSN可以看成是事务提交的序号，这个序号是在事务提交写盘的时候生成的，因此可以说LSN反映了事务提交的顺序。
LSN也会写到InnoDB的数据页中，确保数据页中不会被多次执行重复的redo log。
如图所示三个并发事务 (trx1, trx2, trx3) 在 prepare 阶段，都写完 redo log buffer，持久化到磁盘的过程，对应的 LSN 分别是 50、120 和 160。
MySQL当多个线程在提交完prepare，redo log写入到redo log buffer中，此时，redo log buffer存在多个线程的日志，并同步更新了LSN。第一个写完的线程带着LSN去刷盘，写完后，别的线程发现自己的redo log已经写完了（LSN大于线程的LSN），直接就返回。
如上所示，一个组提交的事务越多，节约磁盘的IOPS效果越好。在并发场景，即使innodb_flush_log_at_trx_commit设置为1，事务每次prepare都要执行刷盘，此时可能有其他的线程也在执行事务，也可以将他们组成一个组实现组提交。
2.5.2 两阶段优化
两阶段提交可以简化为如下两步：
既然组提交能够优化磁盘的IOPS，那就有了如下的优化：
如图所示，把redo log做fysnc的时间拖到了步骤1之后，采用交叉fsync的方式，就是为了收集更多的“提交”，这样的组提交效果更好一些。
这么一来，binlog也可以组提交了。在执行第4步把binlog fsync到磁盘时，如果有多个事务的 binlog 已经写完了，也是一起持久化的，这样也可以减少 IOPS 的消耗。
不过通常情况下第 3 步执行得会很快（redo log顺序写，相对较快），所以 binlog 的 write 和 fsync 间的间隔时间短，导致能集合到一起持久化的 binlog 比较少，因此 binlog 的组提交的效果通常不如 redo log 的效果那么好。
如果想提升 binlog 组提交的效果，可以通过设置 binlog_group_commit_sync_delay 和 binlog_group_commit_sync_no_delay_count 来实现。
这两个条件是或的关系，也就是说只要有一个满足条件就会调用 fsync，当 binlog_group_commit_sync_delay 设置为 0 的时候，binlog_group_commit_sync_no_delay_count 也无效了。
之前我们多次提及的WAL能够减少磁盘写，主要是得益于：
3 MySQL的IO瓶颈优化
分析到这里，我们再来回答这个问题：如果你的 MySQL 现在出现了性能瓶颈，而且瓶颈在 IO 上，可以通过哪些方法来提升性能呢？针对这个问题，可以考虑以下三种方法：
但是并不建议把 innodb_flush_log_at_trx_commit 设置成 0。因为把这个参数设置成 0，表示 redo log 只保存在内存中，这样的话 MySQL 本身异常重启也会丢数据，风险太大。而 redo log 写到文件系统的 page cache 的速度也是很快的，所以将这个参数设置成 2 跟设置成 0 其实性能差不多，但这样做 MySQL 异常重启时就不会丢数据了，相比之下风险会更小。
mysql悲观锁和乐观锁的区别
悲观锁与乐观锁是两种常见的资源并发锁设计思路，也是并发编程中一个非常基础的概念。 本文将对这两种常见的锁机制在数据库数据上的实现进行比较系统的介绍。 悲观锁（Pessimistic Lock）悲观锁的特点是先获取锁，再进行业务操作，即“悲观”的认为获取锁是非常有可能失败的，因此要先确保获取锁成功再进行业务操作。 通常所说的“一锁二查三更新”即指的是使用悲观锁。 通常来讲在数据库上的悲观锁需要数据库本身提供支持，即通过常用的select … for update操作来实现悲观锁。 当数据库执行select for update时会获取被select中的数据行的行锁，因此其他并发执行的select for update如果试图选中同一行则会发生排斥（需要等待行锁被释放），因此达到锁的效果。 select for update获取的行锁会在当前事务结束时自动释放，因此必须在事务中使用。 这里需要注意的一点是不同的数据库对select for update的实现和支持都是有所区别的，例如orACLe支持select for update no wait，表示如果拿不到锁立刻报错，而不是等待，mysql就没有no wait这个选项。 另外mysql还有个问题是select for update语句执行中所有扫描过的行都会被锁上，这一点很容易造成问题。 因此如果在mysql中用悲观锁务必要确定走了索引，而不是全表扫描。 乐观锁（Optimistic Lock）乐观锁的特点先进行业务操作，不到万不得已不去拿锁。 即“乐观”的认为拿锁多半是会成功的，因此在进行完业务操作需要实际更新数据的最后一步再去拿一下锁就好。 乐观锁在数据库上的实现完全是逻辑的，不需要数据库提供特殊的支持。 一般的做法是在需要锁的数据上增加一个版本号，或者时间戳，然后按照如下方式实现：1. SELECT data AS old_data, version AS old_version FROM …;2. 根据获取的数据进行业务操作，得到new_data和new_version3. UPDATE SET data = new_data, version = new_version WHERE version = old_versionif (updated row > 0) {// 乐观锁获取成功，操作完成} else {// 乐观锁获取失败，回滚并重试}乐观锁是否在事务中其实都是无所谓的，其底层机制是这样：在数据库内部update同一行的时候是不允许并发的，即数据库每次执行一条update语句时会获取被update行的写锁，直到这一行被成功更新后才释放。 因此在业务操作进行前获取需要锁的数据的当前版本号，然后实际更新数据时再次对比版本号确认与之前获取的相同，并更新版本号，即可确认这之间没有发生并发的修改。 如果更新失败即可认为老版本的数据已经被并发修改掉而不存在了，此时认为获取锁失败，需要回滚整个业务操作并可根据需要重试整个过程。 总结乐观锁在不发生取锁失败的情况下开销比悲观锁小，但是一旦发生失败回滚开销则比较大，因此适合用在取锁失败概率比较小的场景，可以提升系统并发性能乐观锁还适用于一些比较特殊的场景，例如在业务操作过程中无法和数据库保持连接等悲观锁无法适用的地方
mysql数据库性能测试
我理解的是你希望了解mysql性能测试的方法：其实常用的一般：选取最适用的字段属性MySQL可以很好的支持大数据量的存取，但是一般说来，数据库中的表越小，在它上面执行的查询也就会越快。
因此，在创建表的时候，为了获得更好的性能，我们可以将表中字段的宽度设得尽可能小。
例如，在定义邮政编码这个字段时，如果将其设置为CHAR(255),显然给数据库增加了不必要的空间，甚至使用VARCHAR这种类型也是多余的，因为CHAR(6)就可以很好的完成任务了。
同样的，如果可以的话，我们应该使用MEDIUMINT而不是BIGIN来定义整型字段。
另外一个提高效率的方法是在可能的情况下，应该尽量把字段设置为NOT NULL，这样在将来执行查询的时候，数据库不用去比较NULL值。
对于某些文本字段，例如“省份”或者“性别”，我们可以将它们定义为ENUM类型。
因为在MySQL中，ENUM类型被当作数值型数据来处理，而数值型数据被处理起来的速度要比文本类型快得多。
这样，我们又可以提高数据库的性能。
2、使用连接（JOIN）来代替子查询(Sub-Queries)MySQL从4.1开始支持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 salesinfoON =salesinfo. CustomerID WHERE IS NULL连接（JOIN）.. 之所以更有效率一些，是因为 MySQL不需要在内存中创建临时表来完成这个逻辑上的需要两个步骤的查询工作。
3、使用联合(UNION)来代替手动创建的临时表MySQL 从 4.0 的版本开始支持 UNION 查询，它可以把需要使用临时表的两条或更多的 SELECT 查询合并的一个查询中。
在客户端的查询会话结束的时候，临时表会被自动删除，从而保证数据库整齐、高效。
使用 UNION 来创建查询的时候，我们只需要用 UNION作为关键字把多个 SELECT 语句连接起来就可以了，要注意的是所有 SELECT 语句中的字段数目要想同。
下面的例子就演示了一个使用 UNION的查询。
SELECT Name, Phone FROM client UNION SELECT Name, BirthDate FROM authorUNIONSELECT 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=11WHERE item=book;COMMIT;事务的另一个重要作用是当多个用户同时使用相同的数据源时，它可以利用锁定数据库的方法来为用户提供一种安全的访问方式，这样可以保证用户的操作不被其它的用户所干扰。
5、锁定表尽管事务是维护数据库完整性的一个非常好的方法，但却因为它的独占性，有时会影响数据库的性能，尤其是在很大的应用系统中。
由于在事务执行的过程中，数据库将会被锁定，因此其它的用户请求只能暂时等待直到该事务结束。
如果一个数据库系统只有少数几个用户来使用，事务造成的影响不会成为一个太大的问题；但假设有成千上万的用户同时访问一个数据库系统，例如访问一个电子商务网站，就会产生比较严重的响应延迟。
其实，有些情况下我们可以通过锁定表的方法来获得更好的性能。
下面的例子就用锁定表的方法来完成前面一个例子中事务的功能。
LOCK TABLE inventory WRITESELECT Quantity FROM inventoryWHEREItem=book; inventory SET Quantity=11WHEREItem=book;UNLOCK TABLES这里，我们用一个 SELECT 语句取出初始数据，通过一些计算，用 UPDATE 语句将新值更新到表中。
包含有 WRITE 关键字的 LOCK TABLE 语句可以保证在 UNLOCK TABLES 命令被执行之前，不会有其它的访问来对 inventory 进行插入、更新或者删除的操作。
6、使用外键锁定表的方法可以维护数据的完整性，但是它却不能保证数据的关联性。
这个时候我们就可以使用外键。
例如，外键可以保证每一条销售记录都指向某一个存在的客户。
在这里，外键可以把customerinfo 表中的CustomerID映射到salesinfo表中CustomerID，任何一条没有合法CustomerID的记录都不会被更新或插入到salesinfo中。
CREATE TABLE customerinfo( CustomerID INT NOT NULL , PRIMARY KEY ( CustomerID )) TYPE = INNODB;CREATE TABLE salesinfo( SalesID INT NOT NULL, CustomerID INT NOT NULL, PRIMARY KEY(CustomerID, SalesID), FOREIGN KEY (CustomerID) REFERENCES customerinfo (CustomerID) ON DELETECASCADE) TYPE = INNODB;注意例子中的参数“ON DELETE CASCADE”。
该参数保证当 customerinfo 表中的一条客户记录被删除的时候，salesinfo 表中所有与该客户相关的记录也会被自动删除。
如果要在 MySQL 中使用外键，一定要记住在创建表的时候将表的类型定义为事务安全表 InnoDB类型。
该类型不是 MySQL 表的默认类型。
定义的方法是在 CREATE TABLE 语句中加上 TYPE=INNODB。
如例中所示。
7、使用索引索引是提高数据库性能的常用方法，它可以令数据库服务器以比没有索引快得多的速度检索特定的行，尤其是在查询语句当中包含有MAX(), MIN()和ORDERBY这些命令的时候，性能提高更为明显。
那该对哪些字段建立索引呢？一般说来，索引应建立在那些将用于JOIN, WHERE判断和ORDER BY排序的字段上。
尽量不要对数据库中某个含有大量重复的值的字段建立索引。
对于一个ENUM类型的字段来说，出现大量重复值是很有可能的情况，例如customerinfo中的“province”.. 字段，在这样的字段上建立索引将不会有什么帮助；相反，还有可能降低数据库的性能。
我们在创建表的时候可以同时创建合适的索引，也可以使用ALTER TABLE或CREATE INDEX在以后创建索引。
此外，MySQL从版本3.23.23开始支持全文索引和搜索。
全文索引在MySQL 中是一个FULLTEXT类型索引，但仅能用于MyISAM 类型的表。
对于一个大的数据库，将数据装载到一个没有FULLTEXT索引的表中，然后再使用ALTER TABLE或CREATE INDEX创建索引，将是非常快的。
但如果将数据装载到一个已经有FULLTEXT索引的表中，执行过程将会非常慢。
8、优化的查询语句绝大多数情况下，使用索引可以提高查询的速度，但如果SQL语句使用不恰当的话，索引将无法发挥它应有的作用。
下面是应该注意的几个方面。
首先，最好是在相同类型的字段间进行比较的操作。
在MySQL 3.23版之前，这甚至是一个必须的条件。
例如不能将一个建有索引的INT字段和BIGINT字段进行比较；但是作为特殊的情况，在CHAR类型的字段和VARCHAR类型字段的字段大小相同的时候，可以将它们进行比较。
其次，在建有索引的字段上尽量不要使用函数进行操作。
例如，在一个DATE类型的字段上使用YEAE()函数时，将会使索引不能发挥应有的作用。
所以，下面的两个查询虽然返回的结果一样，但后者要比前者快得多。
SELECT * FROM order WHERE YEAR(OrderDate)<2001;SELECT * FROM order WHERE OrderDate<2001-01-01;同样的情形也会发生在对数值型字段进行计算的时候：SELECT * FROM inventory WHERE Amount/7<24;SELECT * FROM inventory WHERE Amount<24*7;上面的两个查询也是返回相同的结果，但后面的查询将比前面的一个快很多。
第三，在搜索字符型字段时，我们有时会使用 LIKE 关键字和通配符，这种做法虽然简单，但却也是以牺牲系统性能为代价的。
例如下面的查询将会比较表中的每一条记录。
SELECT * FROM booksWHERE name like MySQL%但是如果换用下面的查询，返回的结果一样，但速度就要快上很多：SELECT * FROM booksWHERE name>=MySQLand name
1.根本的区别是它们遵循的基本原则 二者所遵循的基本原则是它们的主要区别：开放vs保守。
SQL服务器的狭隘的，保守的存储引擎与MySQL服务器的可扩展，开放的存储引擎绝然不同。
虽然你可以使用SQL服务器的Sybase引擎，但MySQL能够提供更多种的选择，如MyISAM, Heap, InnoDB, and Berkeley DB。
MySQL不完全支持陌生的关键词，所以它比SQL服务器要少一些相关的数据库。
同时，MySQL也缺乏一些存储程序的功能，比如MyISAM引擎联支持交换功能。
2.性能：先进的MySQL 纯粹就性能而言，MySQL是相当出色的，因为它包含一个缺省桌面格式MyISAM。
MyISAM 数据库与磁盘非常地兼容而不占用过多的CPU和内存。
MySQL可以运行于Windows系统而不会发生冲突，在UNIX或类似UNIX系统上运行则更好。
你还可以通过使用64位处理器来获取额外的一些性能。
因为MySQL在内部里很多时候都使用64位的整数处理。
Yahoo!商业网站就使用MySQL作为后台数据库。
当提及软件的性能，SQL服务器的稳定性要比它的竞争对手强很多。
但是，这些特性也要付出代价的。
比如，必须增加额外复杂操作，磁盘存储，内存损耗等等。
如果你的硬件和软件不能充分支持SQL服务器，我建议你最好选择其他如DBMS数据库，因为这样你会得到更好的结果。
3.发行费用：MySQL不全是免费，但很便宜 当提及发行的费用，这两个产品采用两种绝然不同的决策。
对于SQL服务器，获取一个免费的开发费用最常的方式是购买微软的Office或者Visual Studio的费用。
但是，如果你想用于商业产品的开发，你必须还要购买SQL Server Standard Edition。
学校或非赢利的企业可以不考虑这一附加的费用。
4.安全功能 MySQL有一个用于改变数据的二进制日志。
因为它是二进制，这一日志能够快速地从主机上复制数据到客户机上。
即使服务器崩溃，这一二进制日志也会保持完整，而且复制的部分也不会受到损坏。
在SQL服务器中，你也可以记录SQL的有关查询，但这需要付出很高的代价。
安全性 这两个产品都有自己完整的安全机制。
只要你遵循这些安全机制，一般程序都不会出现什么问题。
这两者都使用缺省的IP端口，但是有时候很不幸，这些IP也会被一些黑客闯入。
当然，你也可以自己设置这些IP端口。
恢复性:先进的SQL服务器 恢复性也是MySQL的一个特点，这主要表现在MyISAM配置中。
这种方式有它固有的缺欠，如果你不慎损坏数据库，结果可能会导致所有的数据丢失。
然而，对于SQL服务器而言就表现得很稳键。
SQL服务器能够时刻监测数据交换点并能够把数据库损坏的过程保存下来。
Microsoft SQL Server 与 MySQL 的区别
发表评论