数据库受住
查看MySQL数据库的死锁日志
1. 使用终端或命令提示符登录到MySQL，输入命令：mysql -h xxxx.xxx.xxx -P 3306 -u username -p解释：xxxx.xxx.xxx是数据库IP地址，username是数据库用户名，输入命令后，会让你输入username对应的密码，就可以登录了
4. 如何分析日志，定位死锁原因看3里面的图，紫色划线部分分析：事务1，等待RECORD LOCKS space id 553 page no 376 n bits 368 index `index_user_id` of table `tbj`.`score_user`，这个位置的X锁事务2，持有RECORD LOCKS space id 553 page no 376 n bits 368 index `index_user_id` of table `tbj`.`score_user`这个地方的S锁事务2，等待这个地方的X锁理论上这个事务2是可以提交的不会，死锁，但是这个事务日志只打印最后一部分死锁，信息，这里面隐含的条件是，事务1也持有RECORD LOCKS space id 553 page no 376 n bits 368 index `index_user_id` of table `tbj`.`score_user`这个地方的S锁，这样，事务2不能加X锁，同时事务1也不能加X锁，产生死锁。
2. Oracle数据库无响应故障处理方式
Oracle数据库无响应故障处理方式
Oracle数据库无响应故障，简单地讲就是数据库实例不能响应客户端发起的请求，客户端提交一个SQL后，就一直处于等待数据库实例返回结果的状态。更严重的现象是客户端根本不能连接到数据库，发起一个连接请求后，一直处于等待状态。Oracle数据库无响应故障怎么处理呢?下面跟我一起来学习Oracle数据库无响应故障的处理方法吧!
无响应的故障现象一般有以下几种：
1.Oracle的进程在等待某个资源或事件
这种现象一般可以从V$SESSION_WAT、V$LATCH、V$LATCHHOLDER等动态视图中检查进程正在等待的资源或事件，而被等待的资源或事件，一直都不能被获取，甚至是很长时间都不可获得。如果这个正在等待的进程持有了其他的资源，则会引起其他的进程等待，这样就很可能引起实例中大范围的会话发生等待。由于进程在等待资源或事件时，通常都处于SLEEP状态，消耗的CPU资源非常少(在等待latch时要稍微多消耗一些CPU资源)，所以从OS来看，CPU的消耗并不高，甚至是非常低。
这种因为等待而引起的个别进程Hang，相对比较容易处理。
2. OracleProcess Spins
所谓Spin，就是指Oracle进程中的代码在执行某个过程时，陷入了循环。在V$SESSION视图中，往往可以看到Hang住的会话，一直处于“ACTIVE”状态。对于这样的会话，用“alter system kill session ‘sid,serial#’”命令也不能完全断开会话，会话只能被标记为“killed”，会话会继续消耗大量的CPU。进程Spins由于是在做循环，CPU的消耗非常大，从OS上明显可以看到这样的进程，通常会消耗整个CPU的资源。
而对于这样的Hang住的会话，处理起来相对比较复杂，并且为了从根本上解决问题，需要超过DBA日常维护所需要的技能。
从故障范围来看，无响应故障可以分为以下几种情况：
1. 单个或部分会话(进程)Hang住
这种情况属于小范围的故障，业务影响相对较小，一般来说只会影响业务系统的个别模块。在一个多应用系统的数据库上面，如果Hang住的会话比较多，则影响的可能是其中的一个应用系统。这里有一个例外，如果Hang住的进程是系统后台进程，如pmon、smon等，则影响的范围就非常大了，最终甚至会影响整个数据库及所有应用系统。还有值得注意的是，即使是少部分会话Hang住，也要及时处理，否则极有可能会扩散到整个系统。
2. 单个数据库实例Hang住
这种情况造成的影响非常大。在这个实例上的所有应用系统均受到严重影响，并且在找到根源并最终解决问题之前，数据库实例往往须要重启。
3. OPS或RAC中的多个实例或所有实例都Hang住
在这种情况下，即使是OPS或RAC，都已经没办法提供高可用特性了。使用这个数据库的所有应用系统将不能继续提供服务，这种情况往往须要重启。
无响应故障成因分析
Oracle数据库无响应，一般主要由以下几种原因引起：
1. 数据库主机负载过高，严重超过主机承受能力
比如应用设计不当，数据库性能低下，活动会话数的大量增加，导致数据库主机的负载迅速增加，数据库不能正常操作，并最终Hang住;主机物理内存严重不足，引起大量的换页，特别是在SGA中的内存被大量换出到虚拟内存时，数据库实例往往就会Hang住。
2. 日常维护不当、不正确的操作引起数据库Hang住
比如归档日志的存储空间满，导致数据库不能归档，引起数据库Hang住;在一个大并发的繁忙的系
统上，对DML操作比较多的大表进行move、增加外键约束等操作也可能使系统在短时间内负载大幅升高，并引起数据库系统Hang住;不正确的资源计划(Resource Plan)配置，使进程得不到足够的CPU等。
3. Oracle数据库的Bug
几乎每个版本都存在着会导致数据库系统Hang住的Bug，这些Bug会在一些特定的条件下触发，特别是在RAC数据库中，引起数据库Hang住的Bug比较多。
4. 其他方面的一些原因
比如在RAC数据库中，如果一个节点退出或加入到RAC的过程中，当进行Resource Reconfiguration时，会使系统冻结一段时间，也有可能使系统Hang住。
以上所描述的几种常见的会导致Oracle数据库实例Hang住的原因中，大部分的情况是可以避免的，只要维护得当，一般不会出现这种故障。对于Oracle数据库Bug所导致的数据库无响应故障，由于是在特定的情况下才会触发，所以如果能够尽量对数据库打上最新版本的补丁，并且熟悉当前版本中会导致系统Hang住的Bug以及触发条件，就能够最大限度地避免这种故障的发生，提高系统的可用性。
那么，在数据库Hang住的情况下，如何去分析并发现导致问题的根源?一方面，由于系统Hang住会导致业务系统不可用，为了能够尽快地恢复业务，须快速地判断问题所在，然后Kill掉引起故障的会话和进程，或者数据库实例不得不重启以迅速恢复业务;但另一方面，如果只是重启数据库或Kill会话和进程来解决问题，在很多情况下是治标不治本的办法，在以后故障随时可能会出现。如何在二者之间进行抉择呢?对于数据库Hang故障的处理，首先是尽可能地收集到系统Hang住时的状态数据，然后尽快地恢复业务，恢复业务后分析收集到的数据，找到数据库系统Hang住的真正原因，然后再进行相应的处理。下一节将详细描述数据库系统Hang住后的处理流程。
无响应故障处理流程
对于Oracle无响应故障的处理，我们可以按下图所示的流程进行。
值得注意的是，上图并不是一个完整的Oracle数据库故障处理流程图，只是处理Oralce数据库无响应这一类特定的故障的流程，只列出了针对这一特定类型故障处理时的关键处理点。不过既然是故障，所以这类故障的处理流程与其他故障的处理流程，有着非常相似的地方。
下面是整个流程的详细说明：
1. 在出现数据库无响应故障后，首先确认系统的影响范围，如上节所描述的'，是部分业务系统或模块还是所有的业务系统都受影响，是不是整个实例或多个实例都无响应。同时应询问系统维护和开发人员，受影响的系统在出现故障前是否有过变动，包括主机硬件、操作系统、网络、数据库以及应用等。有时一个细小的变动就可能导致出现数据库Hang住这样严重的故障。曾经遇到一个库，应用只是修改了一个SELECT语句就导致了数据库Hang住。
2. 为了避免由于网络、数据库监听或客户端因素影响分析，建议都登录到主机上进行操作。
3. 如果主机不能登录(为了避免干扰流程主线，这里不讨论如网络问题这样也会导致不能连接的故障)，尝试关闭出现问题的业务系统，甚至是所有的业务系统。如果关闭了所有的业务系统之后，仍然不能连接，则只有考虑重新启动数据库主机。在数据库主机重新启动后，使用操作系统工具或OSW等长期监控操作系统的资源使用，同时监控Oracle数据库的性能和等待等。
4. 登录上主机后，先用top、topas等命令简单观察一下系统。看看系统的CPU使用、物理内存和虚拟内存的使用、IO使用等情况。
5. 使用SQLPLUS连接数据库，如果不能连接，则只能从操作系统上观察系统中是否有异常的现象，比如占用CPU过高的进程。使用gdb、dbx等debugger工具对数据库进行system state mp;使用strace、truss等工具检查异常进程的系统调用;使用pstack、procstack等工具察看异常进程的call stack等。
6. 使用SQLPLUS连接上数据库后，进行hanganalyze、system state mp等操作;或检查等待事件、异常会话等正在执行的SQL等待。
7. 找到故障产生的原因，如果暂时找不到原因，尽量收集数据。
8.确良如果应用急须恢复，可通过Kill会话、重启数据库实例等方式，先恢复应用。
9. 根据最终诊断结果，对数据库升级打补丁，或者修改应用等方式从根本上解决问题。
怎样避免数据库出现无响应故障
作为Oracle数据库DBA，除了处理故障之外，更重要的是如何预防故障的发生。根据前面对数据库无响应故障的成因分析，在日常的维护工作中，须做到以下几点：
1. 进行正确的维护操作
很多的数据库无响应故障都是由于不正确的维护操作引起的。应避免在业务高峰期做大的维护操作，比如像move、加主外键约束等会长时间锁表的操作。如果的确需要，尽量使用正确的操作方法。比如用ONLINE方式重建索引;建主键、唯一键约束时先建索引，然后在建约束时指定新建的索引，等等。也就是保证系统的并发性、可伸缩性，避免系统串行操作的出现。
2. 优化应用设计，优化数据库性能
为避免性能问题导致在业务高峰期数据库不能及时有效处理来自业务的请求，甚至于完全Hang住。对于数据库中存在串行访问的部分进行优化，比如latch、enqueue，还包括不合理的sequence设计等。特别是在RAC数据库中，严重串行访问等待往往更容易引起严重的性能问题。优化应用设计，使数据库具有更好的可伸缩性和并行处理能力，能够有效地避免性能问题引起的数据库Hang住。
3. 利用监控系统随时监控系统负载
遇到系统负载过高，内存不足，OS中虚拟内存换页很频繁等情况时，及时采取措施;监控Oracle数据库的核心进程，如pmon、smon等，看是否有异常，如过高的CPU消耗。出现异常应立即处理;监控归档空间和日志切换;监控数据库中的等待事件，比如是否有大量的enqueue、log file switch (archiving needed)、resmgr:become active等待事件等。
4. 为数据库打上补丁
很多的无响应故障是由于Oracle的Bug引起的，数据库DBA应关注当前版本中有哪些Bug会导致数据库Hang住，尽量为数据库打上解决这些Bug的补丁。
;3. 数据库索引是什么，有什么用，怎么用
1、数据库索引是什么，有什么用
数据库索引是对数据库表中一列或多列的值进行排序的一种结构，使用索引可快速访问数据库表中的特定信息。如果想按特定职员的姓来查找他或她，则与在表中搜索所有的行相比，索引有助于更快地获取信息。
索引的一个主要目的就是加快检索表中数据的方法，亦即能协助信息搜索者尽快的找到符合限制条件的记录ID的辅助数据结构。
2、数据库索引的用法
当表中有大量记录时，若要对表进行查询，第一种搜索信息方式是全表搜索，是将所有记录一一取出，和查询条件进行一一对比，然后返回满足条件的记录，这样做会消耗大量数据库系统时间，并造成大量磁盘I/O操作；
第二种就是在表中建立索引，然后在索引中找到符合查询条件的索引值，最后通过保存在索引中的ROWID（相当于页码）快速找到表中对应的记录。
索引是一个单独的、物理的数据库结构，它是某个表中一列或若干列值的集合和相应的指向表中物理标识值的数据页的逻辑指针清单。
(3)数据库受住扩展阅读：
一、索引的原理：
对要查询的字段建立索引其实就是把该字段按照一定的方式排序；建立的索引只对该字段有用，如果查询的字段改变，那么这个索引也就无效了，比如图书馆的书是按照书名的第一个字母排序的，那么你想要找作者叫张三的就不能用改索引了；还有就是如果索引太多会降低查询的速度。
二、数据库索引的特点：
1、避免进行数据库全表的扫描，大多数情况，只需要扫描较少的索引页和数据页，而不是查询所有数据页。而且对于非聚集索引，有时不需要访问数据页即可得到数据。
2、聚集索引可以避免数据插入操作，集中于表的最后一个数据页面。
3、在某些情况下，索引可以避免排序操作。
4. 哪些因素影响了数据库性能
网络宽带，磁盘IO，查询速度都会影响到数据库的性能。
具体问题具体分析，举例来说明为什么磁盘IO成瓶颈数据库的性能急速下降了。
为什么当磁盘IO成瓶颈之后, 数据库的性能不是达到饱和的平衡状态，而是急剧下降。为什么数据库的性能有非常明显的分界点，原因是什么？
相信大部分做数据库运维的朋友，都遇到这种情况。 数据库在前一天性能表现的相当稳定，数据库的响应时间也很正常，但就在今天，在业务人员反馈业务流量没有任何上升的情况下，数据库的变得不稳定了，有时候一个最简单的insert操作， 需要几十秒，但99%的insert却又可以在几毫秒完成，这又是为什么了？
dba此时心中有无限的疑惑，到底是什么原因呢? 磁盘IO性能变差了？还是业务运维人员反馈的流量压根就不对？ 还是数据库内部出问题？昨天不是还好好的吗？
当数据库出现响应时间不稳定的时候，我们在操作系统上会看到磁盘的利用率会比较高，如果观察仔细一点，还可以看到，存在一些读的IO. 数据库服务器如果存在大量的写IO,性能一般都是正常跟稳定的，但只要存在少量的读IO,则性能开始出现抖动，存在大量的读IO时（排除配备非常高速磁盘的机器），对于在线交易的数据库系统来说，大概性能就雪崩了。为什么操作系统上看到的磁盘读IO跟写IO所带来的性能差距这么大呢？
如果亲之前没有注意到上述的现象，亲对上述的结论也是怀疑。但请看下面的分解。
在写这个文章之前，作者阅读了大量跟的IO相关的代码，如异步IO线程的相关的，innodb_buffer池相关的，以及跟读数据块最相关的核心函数buf_page_get_gen函数以及其调用的相关子函数。为了将文章写得通俗点，看起来不那么累，因此不再一行一行的将代码解析写出来。
咱们先来提问题。buf_page_get_gen函数的作用是从Buffer bool里面读数据页，可能存在以下几种情况。
提问. 数据页不在buffer bool 里面该怎么办？
回答：去读文件，将文件中的数据页加载到buffer pool里面。下面是函数buffer_read_page的函数，作用是将物理数据页加载到buffer pool, 图片中显示
buffer_read_page函数栈的顶层是pread64(),调用了操作系统的读函数。
通过解析buf_wait_for_read函数的下层函数，我们知道其实通过首先自旋加锁pin的方式，超过设定的自旋次数之后，进入等待，等待IO完成被唤醒。这样节省不停自旋pin时消耗的cpu,但需要付出被唤起时的开销。
再继续扩展问题： 如果会话线程A 经过物理IO将数据页1001读入buffer之后，他需要修改这个页，而在会话线程A之后的其他的同样需要访问数据页1001的会话线程，即使在数据页1001被入读buffer pool之后，将仍然处于等待中。因为在数据页上读取或者更新的时候，同样需要上锁，这样才能保证数据页并发读取/更新的一致性。
由此可见，当一个高并发的系统，出现了热点数据页需要从磁盘上加载到buffer pool中时，造成的延迟，是难以想象的。因此排在等待热点页队列最后的会话线程最后才得到需要的页，响应时间也就越长，这就是造成了一个简单的sql需要执行几十秒的原因。
再回头来看上面的问题，mysql数据库出现性能下降时，可以看到操作系统有读IO。 原因是，在数据库对数据页的更改，是在内存中的，然后通过检查点线程进行异步写盘，这个异步的写操作是不堵塞执行sql的会话线程的。所以，即使看到操作系统上有大量的写IO，数据库的性能也是很平稳的。但当用户线程需要查找的数据页不在buffer pool中时，则会从磁盘上读取，在一个热点数据页不是非常多的情况下，我们设置足够大的innodb_buffer_pool的size, 基本可以缓存所有的数据页，因此一般都不会出现缺页的情况，也就是在操作系统上基本看不到读的IO。 当出现读的IO时，原因时在执行buf_read_page_low函数，从磁盘上读取数据页到buffer pool, 则数据库的性能则开始下降，当出现大量的读IO，数据库的性能会非常差。
5. MYSQL数据库怎么查看 哪些表被锁了
以下五种方法可以快速定位全局锁的位置，仅供参考。
方法1：利用 metadata_locks 视图
此方法仅适用于 MySQL 5.7 以上版本，该版本 performance_schema 新增了 metadata_locks，如果上锁前启用了元数据锁的探针（默认是未启用的），可以比较容易的定位全局锁会话。
方法2：利用 events_statements_history 视图此方法适用于 MySQL 5.6 以上版本，启用 performance_schema.eventsstatements_history（5.6 默认未启用，5.7 默认启用），该表会 SQL 历史记录执行，如果请求太多，会自动清理早期的信息，有可能将上锁会话的信息清理掉。
方法3：利用 gdb 工具如果上述两种都用不了或者没来得及启用，可以尝试第三种方法。利用 gdb 找到所有线程信息，查看每个线程中持有全局锁对象，输出对应的会话 ID，为了便于快速定位，我写成了脚本形式。也可以使用 gdb 交互模式，但 attach mysql 进程后 mysql 会完全 hang 住，读请求也会受到影响，不建议使用交互模式。
方法4：show processlist
如果备份程序使用的特定用户执行备份，如果是 root 用户备份，那 time 值越大的是持锁会话的概率越大，如果业务也用 root 访问，重点是 state 和 info 为空的，这里有个小技巧可以快速筛选，筛选后尝试 kill 对应 ID，再观察是否还有 wait global read lock 状态的会话。
方法5：重启试试！
6. 影响数据库性能的主要因素有哪些
以MySQL为例：
影响数据库性能的主要因素总结如下：
1、sql查询速度
2、网卡流量
3、服务器硬件
4、磁盘IO
以上因素并不是时时刻刻都会影响数据库性能，而就像木桶效应一样。如果其中一个因素严重影响性能，那么整个数据库性能就会严重受阻。另外，这些影响因素都是相对的。
例如：当数据量并没有达到百万千万这样的级别，那么sql查询速度也许就不是个重要因素，换句话说，你的sql语句效率适当低下可能并不影响整个效率多少，反之，这种情况，无论如何怎么优化sql语句，可能都没有太明显的效果。
相关内容拓展：
1、SQL查询速度
风险：效率低下的SQL
2、网卡流量
风险：网卡IO被占满（100Mb/8=100MB）
方案：
①减少从服务器的数量。从服务器都要从主服务器上复制日志，所以，从服务器越多，网络流量越大。
②进行分级缓存。前方大量缓存突然失效会对数据库造成严重的冲击。
③避免使用“select * ”进行查询
④分离业务网络和服务器网络
3、磁盘IO
风险：磁盘IO性能突然下降。
方案：使用更好的磁盘设备解决。
7. 数据库的作用
1、帮助企业准确找到目标客户：
在市场细分化理论指导下的营销，是根据人口统计及消费者共同的心理特点，将客户划归为某一类别。而通过新一代高速计算机和数据库技术，以使企业能够集中精力于更少的人身上，最终目标集中在最小消费单位——特定企业或个人身上，实现准确定位。
2、降低营销成本，提高营销效率：
运用数据库能够准确找出某种产品的目标客户，用数据库技术进行筛选消费者，其邮寄宣传品的反馈率可以高达20%～30％。
3、使消费者成为企业长期、忠诚的用户，保证企业掌握稳定的客户群：
建立数据库，以便能够分析客户是些什么人，采取什么措施以保住客户。当通过数据库锁定企业的重点客户后，企业每次举行促销宣传活动，必以这部分客户为主要对象，极力改进服务，满足他们的需求，使这些客户成为公司稳定的客户。
(7)数据库受住扩展阅读：
数据库的优点：
1、查询迅速、准确，且有多种表达与传输方式：
如果要查找的内容较多，则查找与抄写既费时又费力。数据库系统能根据给定的条件自动地按一定途径以毫秒级速度进行扫描查找，可以在瞬间将符合要求的数据一一用表格或其他方式显示出来，还可以自动地打印出来或通过网络传输到指定地址，而且不会出现错误。
2、数据结构化且统一管理：
在数据库中，数据按逻辑结构组织起来，而按物理结构存放在磁介质中，并且由数据库管理系统统一管理，既考虑了数据本身的特点，也考虑了数据之间以及文件之间的联系，数据的查询、检索和处理很方便。
8. ora-12719 操作要求数据库 处于restricted模式下 怎么处理
数据库受限模式，在这个模式下只有RESTRICTED SESSION 权限的人才可以登陆，一般用与数据库维护的时候使用。
RESTRICTED SESSION Clause
The RESTRICTED SESSION clause lets you restrict logon to Oracle.
You can use this clause regardless of whether your instance has the database
dismounted or mounted, open or closed.
Restricting Session Logons: Example You may want to restrict logons if you are
performing application maintenance and you want only application developers
with RESTRICTED SESSION system privilege to log on. To restrict logons, issue the
following statement:
ALTER SYSTEM
9. 数据库承载问题
MySQL∶网站开发者的新选择
“变动”这两个字对 IT 业界来说是再普通不过的事了。如果今天管理阶层的主管们跟你要数据库的推荐名单，很可能在你开始执行你所推荐的方案之前，你的推荐名单上的项目就已经过时了。 如此一来，你可能就要重新考虑各种软硬件方案，好让你∶
·帮你将事情完成
·买来以便帮助别人完成他们的工作
·开发以便帮助别人更好地完成他们的工作
不论你的消息有多新，在你的建议通过层层关卡，并且拿到购买资金之前，你的推荐表上的某些项目通常都会过时。幸运的是，没有人会责怪你，或者是对你反唇相讥 -- 这是这一行里很自然的事情。数据库技术通常在你能够掌握它之前就变了。
为了适应日新月异的数据库技术，有相当多的软件工程师逐渐地从桌面数据库软件诸如 Microsoft Access 以及 SQL Server，转到使用 MySQL。虽然严格说来MySQL 并非 SQL Server 的对手，但许多服务提供商都支持 MySQL，并视之为便宜而有效率的替代品。
Susan Sales Harkins 经常在 CNET Builder.com 发表文章，是一位精通微软 Office 的专家。她也是Using Microsoft Access 97和Using Microsoft Access 2000两书的作者，这两本书均由 Que 所出版。
Martin W. P. Reid 也经常在 CNET Builder.com 发表文章，是英国贝尔法斯特女王大学（Queen's University） 的分析师暨程序设计员。他也指导关系型数据库设计的课程；工作之余也为北爱尔兰的一些小型企业充当数据库顾问。
▲考虑使用 MySQL 的原因
如果你要找的是可靠的数据库软件，以便支持你的网站开发工作，那么以下的原因就说明了你为什么应该考虑 MySQL而不是其它数据库∶
·它便宜（通常是免费）。
·它的网络承载比较少。
·它经过很好的优化（Highly Optimized）。
·应用程序通过它做备份来比较简单。
·它为各种不同的资料格式提供有弹性的扩展接口 (ODBC)。
·它较好学，且操作简单。
·你负担得起的客户支持费用。
▲关于“$”的问题
简单的说，你不会找到比 MySQL 更便宜的了。事实上，对大多数用户来说，MySQL 是免费的。有时候虽然是要付出一小笔的授权费，但是这个付费规定只限于以下两种情况∶
·以内嵌（embedded）的方式使用 MySQL 服务器
·只使用 MySQL 的商业用途软件
例如，Windows 版本的 MySQL 服务器，需要授权。虽然只付比美金 $200 元多一点点的费用，MySQL 还是比其他任何数据库软件来得更便宜多了。Office XP Developer 的零售价是美金 $799 元，升级版则是美金 $549 元。Access 2002 的价格是美金 $339 元，升级版则是美金 $109 元。
▲ 避免堵塞
针对多个使用者共同读写信息的需求，Access 根本不是 MySQL 的对手。Access 在大约十五个使用者连上来的时候，就输掉了。我们还听说过当只有五个人连上来时， 就会有一些问题（这并不是说，只有五个人能够同时连上由 Access 数据库支持的网站）。“同时连结”（Simultaneous connection）事实上是一种并发处理（concurrent process）。因此，虽然事实上 Access 可以处理的连结数目是无限制的，但只要那些连结保持在并发处理的范围限制内就没关系。对于只读网站（这些网站并非你想象中的少数）它可以支持到最多到 255 个使用者。而较大的网站，则无可避免的必须升级到 SQL Server 以提高稳定性和效率。
相对说来，MySQL 内定最大连结数为 100 个使用者。但是，我们绝对不可以用一个程序的内建设定来判断它的效能。到目前为止，我们还没听说过使用 MySQL 的较大而且访问频繁的网站上的使用者有任何抱怨。除此之外，即使有网络上有 大量 的资料往来，似乎并不会对MYSQL的查询优化（query optimization）造成多大的影响。
在 Windows 98 操作系统上使用相同的硬件和数据尺寸，MySQL 表现得比 Access 2000 还要快 – 但只是并非所有的情况下都是如此。 这两者在资料更新方面的效能，有着很大的差异，同样的资料更新，Access 要花上两倍的时间。如果是在高速系统上做小量的资料的处理，你不会去注意到这两者间的差异。 但只有在处理的是几十万笔资料的时候，这效能上的差异才会明显。MySQL 只在处理数据库对象结构（object structure）的时候，才会输给 Access。 当建立表格（table） 以及索引的时候，MySqL 会将表格锁住，如此一来会导致正在进行的大量资料处理速度慢下来。然而以上所提到的最后一个问题在网站开发时，通常并不会造成麻烦。 因为网站上，我们所重视的是用户来访时查询的速度，而非资料储存结构本身。因此，在这个领域，MySQL 胜利。
▲MYSQL其它的优点
·优化
对于 MySQL 的优化，我们可以说，主要的问题在于你的硬件条件，而非 MySQL 本身。不过对于 Access，（以及其他桌面数据库软件）事情就不是这样了。 没错，Microsoft Jet Database 的确实有效率，不过它还不是最快的。如果你的数据库设计得非常差，你的网站还是会受到影响而速度变慢的。 数据库结构设计也会影响到 MySQL，例如，MySQL 并不支持外键（foreign key）。这个缺点会影响到你的数据库设计以及网站的效率。对于使用 MySQL 做数据库的网站，你应该注意的是，如何让硬盘存取IO减少到最低值、如何让一个或多个 CPU 随时保持在高速作业的状态、以及适当的网络带宽， 而非实际上的数据库设计以及资料查询语句。事实上，有些网站开发者将 MySQL 称为目前市面上跑得最快的数据库。不过，当你的数据库有很多表格需要同时在一个事务过程（transaction）内完成更新的时候，MySQL 的确跑得不怎么样。
·备份
如果你曾经有过抢救一个损坏的 MDB 档案的惨痛经验，那么你会对 MySQL 表示非常激赏。这是 MySQL 另一个胜过 Access 的地方。首先，mysqlmp 会产生一个比 Access 好很多而且也更可靠的备份档案。相比之下，在 Access中你只是将一个 MDB 档拷贝起来做备份。其次，即使 MySQL 的备份有部分损坏，复原起来也要比一个损坏的 MDB 档要容易得多了。
·可延伸性（Scalability）以及资料处理能力
套句登山者的话来说，将 Access 数据库来跟 MySQL 相比，简直就是像把印第安那的小山丘拿来跟科罗拉多洛矶山脉的 Pike's Peak 顶相比较。事实就是这么简单∶MySQL 可以处理的档案比 Access 所能处理的档案大很多。如果你硬将 Access 数据库弄到 100MB 的 MDB 档案时，你要准备好一个字典厚的纪录本来记录来自客户对于网站效率低下的抱怨。而类似的数据库在 MySQL 上面跑，就不会发生承载过重的迹象。
另外，MySQL 同时提供高度多样性，能够提供很多不同的使用者接口，包括命令行客户端操作，网页浏览器，以及各式各样的程序语言接口，例如 C+，Perl，Java，PHP，以及 Python。你可以使用事先包装好的客户端，或者干脆自己写一个合适的应用程序。MySQL 可用于 Unix，Windows，以及 OS/2 等平台，因此它可以用在个人电脑或者是服务器上。
没错，Microsoft ActiveX Data Objects Library（ADO）的确使得 Access 在外部资料市场（foreign data market）上能够做更具弹性的应用。它能够让你不用管资料的所在位置而取出资料，然后在公用的接口上（即网页浏览器）将资料显示出来。不过，其坏处是 ADO 毕竟是比较笨重（它本身就是个资源大杂烩）而且学习它要花不少的金钱跟时间，就算你是一个能力不错的开发工程师或者软件工程师也一样。没有人能在一天内将 ADO 学会。
▲学习曲线
如果你已经熟悉数据库技术，那么基本上你已经没什么问题了。精通数据库的人在一天之内就可以把 MySQL 学会，把这个经验加到他的履历表里面去。相较之下，Access 是个复杂得多的数据库及开发工具。即使是一个能力不错的开发工程师也需要一段时间才能具备足够的专业知识，有效地使用这个软件。
正如你期待的，MySQL 支持结构化查询语言（Structured Query Language ,SQL）。如果你已经学会某种版本的 SQL 语言，事情会好办很多。具有 VB 或者是 VBA 知识背景的开发工程师会发现，他们以前所具备的 ASP 背景，能够帮助他们缩短学习时间。
▲客户支持
虽然好用而且免费的客户支持已不存在，然而MySQL 倒提供了一些电子群组名单供您参考。有一些是颇具技术性的，而且会员们往往互相提供最佳的客户支持 -- 他们彼此分享经验和专业知识。此外，你还可以购买具有 客户支持 的版本，包括 email 支持或者电话支持的方式。大致上来说，客户支持费率并非固定的，因此我们无法提供你相关价位的信息。
▲MySQL 的不足之处
Access 是一个关联性数据库管理系统（RDBMS），然而 MySQL 并非在每一个层面都是如此。这表示，虽然 MySQL 很好用，它还不是最好的。 以下列表记录了目前关联性层面以及管理层面，MySQL 尚未支持的部分:
MySQL 没法处理复杂的关联性数据库功能，例如，子查询（subqueries），虽然大多数的子查询都可以改写成 join。我们期待下一版出来时，这项功能会被加进来。
另一个 MySQL 没有提供支持的功能是事务处理（transaction）以及事务的提交（commit）/撤销（rollback）。 一个事务指的是被当作一个单位来共同执行的一群或一套命令。如果一个事务没法完成，那么整个事务里面没有一个指令是真正执行下去的。对于必须处理线上订单的商业网站来说， MySQL 没有支持这项功能，的确让人觉得很失望。 但是可以用MaxSQL，一个分开的服务器，它能通过外挂的表格来支持事务功能。
外键（foreign key）以及参考完整性限制（referential integrity）可以让你制定表格中资料间的约束，然后将约束（constraint）加到你所规定的资料里面。这些MYSQL没有的功能表示一个有赖复杂的资料关系的应用程序并不适合使用 MySQL。 当我们说 MySQL 不支持外键时，我们指的就是数据库的参考完整性限制 -- MySQL 并没有支持外键的规则，当然更没有支持连锁删除（cascading delete）的功能。 简短的说，如果你的工作需要使用复杂的资料关联，那你还是用原来的 Access 吧。
你在 MySQL 中也不会找到存储进程（stored procere）以及触发器（trigger）。（针对这些功能，在 Access 提供了相对的事件进程（event procere）。）
Access 的 GetRows 功能，提供了较好的资料拾取。
▲总结
下面这个表格能让你对于 MySQL，Access，以及 SQL Server 大致上比起来是怎么样有个基本概念:
□访问频繁的网站
·MySQL √
·Access √**
·SQL Server √
□复杂的资料关联
·MySQL ×
·Access √
·SQL Server √
□在线订单处理
·MySQL √*
·Access √***
·SQL Server √
□兼容性
·MySQL ×
·Access √****
·SQL Server √
□易于使用及操作
·MySQL √
·Access ×
·SQL Server ×
注：
* 需要MaxSQL
** 前提是资料只读的话
*** 通过Jet SQL获得的附加功能
**** 因为只有ADO
如果你需要使用复杂的数据库，并且有很多资源和金钱，那么你就用 SQL Server 吧。如果你仍旧需要复杂的数据库但是却没有雄厚的后援，那么用 Access 看看。至于其他的人，至少应该给 MySQL 一个使用的机会吧！