目录
一、引擎比较
（一）、MySQL引擎：支持ISAM、MYISAM、MEMORY（HEAP）、INNODB和BERKLEY五种引擎类型。
ISAM（磁盘表）:适用于查询次数要远大于更新次数的数据库设计，执行读取操作的速度很快，而且不占用大量的内存和存储资源。ISAM存在缺点：不支持事务处理，不支持行级锁，也不能够容错，数据无法恢复。
MyISAM（磁盘表）：其依然强调了快速读取操作（读取速度最快），是MySQL的ISAM扩展格式和缺省的数据库引擎，其不仅提供了索引和字段管理，还通过表格锁定的机制，来优化多个并发的读写操作。MyISAM存在缺点：不支持事务处理，不支持行级锁，表损坏后数据无法恢复。
MEMORY（HEAP）（内存表）：由于是在内存中其操作速度很快，但是管理的数据是不稳定的，容易造成数据丢失。如果数据被删除之后，容易造成浪费空间。
InnoDB和BERKLEY（磁盘表）：InnoDB是MySQL默认的引擎，造就MySQL灵活性，完美的解决了前两个类型的不支持事务、不支持外来键以及不支持行级锁的问题，通过MySQL+API实现引擎（DELETE FROM table时，InnoDB不会重新建立表，而是一行一行的删除）。
（二）、引擎的索引结构比较：
B+tree（B+树）和B-tree（B树），我们大部分都是采用的这种两种作为索引结构。
B-tree：是一个种多路搜索树，即使用B-tree可以减少定位记录时所经历的中间过程，从而加快存取的速度。
其特征如下：
1、关键字集合分布在整棵树的所有节点之中；
2、搜索有可能在非叶子节点结束；
3、任何一个关键字出现且只出现在一个结点中。
B-tree的搜索从根结点开始，对结点内的关键字序列进行二分查找，如果命中则结束，否则进入查询关键字所属范围的儿子结点，重复执行这个操作，直到所对应的节点指针为空或者已经是叶子节点。
B+tree属于B-tree的变种，相对于B-tree，其有更好的优势：
1、磁盘的IO代价更低；
2、查询效率更加稳定；
3、所有叶子节点形成了一个有序的链表，更加方便查找。
InnoDB和MyISAM是使用B+tree作为索引结构。
（三）、Oracle引擎：Oracle是不存在引擎的概念的，其数据处理可以分为两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。
OLTP：强调数据库内存效率，强调内存各种指标的命令率，强调绑定变量，强调并发操作。是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。
OLAP：强调数据分析，强调SQL执行市场，强调磁盘I/O，强调分区等.是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。
二、事务支持
事务的概念：事务是把对数据库的一系列操作都看做一个整体，要么全部成功，要么全部失败，利用事务我们可以保证数据库的完整性，事务具有原子性。
（一）、事务的特性（ACID）
1、原子性（Atomicity）：事务中所涉及的程序对数据库的修改操作要么全部成功，要么全部失败。
2、一致性（Consistency）：事务执行前和执行后来源和去向保持平衡。
3、隔离性（Isolation）：并发时每个事务是隔离的，相互不影响。
4、持久性（Durubility）：一旦事务成功提交，应该保证数据的完整存在。
（二）、.事务隔离级别
1、read uncommitted 未提交读（脏读）。
2、read committed 提已交读 。
3、repeatable 可重复读。
4、Serializable可串行化
（三）、MySQL和Oracle支持事务级别
Oracle支持两种事务级别：READ COMMITTED ：读已提交和SERIALIZABLE：串行读取，其默认隔离级别为：读已提交（READ COMMITTED）
MySQL支持四种隔离级别，默认隔离级别：可重复读 (Repeated read)
三、高并发数据库优化
（一）、表设计优化：如果数据库模型设计不合理，不仅会增加客户端和服务器端的维护难度，还会影响系统运行性能。一般在系统运行初期，数据量较小，我们很容易忽略到模型设计的合理性和系统性能。所以在系统设计之初的时候要考虑到在高并发情况下的运行性能。我们要在设计时，要尽可能的考虑多方面，在保证尽可能低冗余的同时也要考虑关联查询时的性能。当数据冗余低的时候，数据的完整性容易得到保证，提高了数据吞吐速度，保证了数据的完整性。但是多表之间的关联查询时，则性能将会降低，同时也提高了客户端程序的编程难度。
优化点如下：
1、合理增加有效的索引（如聚合索引、单列索引等）。索引有助于提高检索性能，但过多或不当的索引也会导致系统低效。因为用户在表中每加进一个索引，数据库就要做更多的工作。过多的索引甚至会导致索引碎片。
2、灵活选用合理的字段类型（对于不可变字符类型char和可变字符类型varchar 都是8000字节,char查询快，但是耗存储空间，varchar查询相对慢但是节省存储空间。例如用户名、密码等长度变化不大可以选择CHAR，对于评论等长度变化大的字段可以选择VARCHAR）。
3、字段长度在合理的情况下尽可能短一些。
（二）、SQL优化
1、在使用select 查询时，尽可能将索引列放在选择的首列，少使用select * from table，要用到几列就选择几列，如SELECT COL1,COL2 FROM table。
2、查询时正确使用索引（如果是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致），增加查询效率。
3、避免在 where 子句中对字段进行 null 值判断。
4、避免在 where 子句中使用!=或<>操作符。
5、避免在 where 子句中使用 or 来连接条件，可以使用union all来解决。
6、尽可能的少用in 和 not in ，in会使系统无法使用索引。如果不可避免时要注意合理使用in和exists的区别。例如select * from A where id in(select id from B)； in()适合B表比A表数据小的情况，exists()适合B表比A表数据大的情况。
7、避免在索引过的字符数据中，使用非打头字母搜索。这也使得引擎无法利用索引。如下：SELECT * FROM T1 WHERE NAME LIKE ‘L%’；像like查询，只有这种才会走索引。
8、避免在 where 子句中对字段进行表达式操作和函数操作。
9、避免在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算。
10、校验表里是否存在某条纪录，不要用count(*)那样效率很低，可以用EXISTS代替。
11、能用UNION ALL就不要用UNION。
12、尽量不要用SELECT INTO语句。其会导致表锁定，阻止其他用户访问该表。
13、尽可能的用DISTINCT代替GROUP BY。如果必须使用GROUP BY， 可以通过将不需要的记录在GROUP BY 之前过滤掉来提高GROUP BY 语句的效率。
14、通过视图可以增加查询速度。
15、避免频繁创建和删除临时表，以减少系统表资源的消耗。