数据库优化相关知识

爱被打了一巴掌 2022-03-06 12:10 331阅读 0赞

<table> 
 <tbody> 
 <tr> 
 <td> 
 <ul> 
 <li>数据库主从复制</li> 
 <li>缓存一致性问题</li> 
 <li>数据库分表策略</li> 
 <li>MVCC</li> 
 <li>死锁</li> 
 </ul></td> 
 </tr> 
 </tbody> 
</table>

实际问题 ，可以参考 ：[线上慢查询？试试这几个优化思路！][Link 1]

....单个MySQL实例可能很快就无法支撑业务的增长，按照业界主流做法，那需要拆库拆表，拆业务线，做横向扩展以支撑更大的业务压力。拆库拆表之后又会遇上讨厌的CAP理论，分布式事务等等一堆麻烦事，需要组建一个几十人的SOA服务化团队来做分布式服务架构……总之一堆事...(摘自 [深度推荐：创业团队为什么要选择Oracle而不是MySQL？][Oracle_MySQL])

**Memcache内存缓存技术、静态化技术、mysql优化**

### **mysql优化** ###

参考  [数据库SQL优化大总结之 百万级数据库优化方案][SQL_] [(有的地方有错)][SQL_]

索引 读写分离的优化 缓存

### 数据库主从复制 ###

MySQL 主从复制是指数据可以从一个MySQL数据库服务器主节点复制到一个或多个从节点。MySQL 默认采用异步复制方式，这样从节点不用一直访问主服务器来更新自己的数据，数据的更新可以在远程连接上进行，从节点可以复制主数据库中的所有数据库或者特定的数据库，或者特定的表。

**MySQL 主从复制主要用途**

**1 读写分离**

2**数据实时备份**，当系统中某个节点发生故障时，可以方便的故障切换

3 **架构扩展**

主从形式:   (参考  [深度探索MySQL主从复制原理][MySQL] )

一主一从和一主多从是最常见的主从架构，实施起来简单并且有效，不仅可以实现HA，而且还能读写分离，进而提升集群的并发能力。

![20190322213040698.png][]

MySQL 主从复制默认是异步的模式**。MySQL增删改操作会全部记录在binary log中(mysql中的文件)**，当slave节点连接master时，会主动从master处获取最新的bin log文件。并把bin log中的sql relay。

(参考  [【MySQL】通过Binary Log简单实现数据回滚（一）][MySQL_Binary Log][https://www.cnblogs.com/joemsu/p/8868300.html][MySQL_Binary Log])

Binary Log（二进制文件），包含了描述数据库更改的“事件”，例如创建表的操作或者改变表的数据。如果采用基于行的日志，它还能包含已经发生更改的语句事件（比如，没有对应行的DELETE事件）。

也就是说你对数据库的操作，包括INSERT、DELETE在内的CRUD，binlog（命令里简称）都会包含进去，那么，如果我们能够**解析**（因为从binlog的名字可以知道，这是一个二进制文件，不是人类能够阅读的）出它的内容，就可以对执行的语句进行反向操作，对误操作的数据进行恢复。

这也是binlog的目的之一：[数据恢复][Link 2]  ; 而binlog的另一个用途就是用于主从复制。我们都知道在现在的大数据背景下，常规的单数据库已经无法满足访问量的需求，于是出现了数据库集群：主数据库进行写操作，从数据库进行读操作，从而降低数据库的访问压力，而**为了保证数据库的内容一致，就要用到binlog来保证了**.

### MySQL 内部处处皆缓存: ###

(参考 [https://www.jb51.net/article/108177.htm][https_www.jb51.net_article_108177.htm])

1.  查询缓存优化
2.  结果集缓存
3.  排序缓存
4.  join 连接缓存
5.  表缓存Cache 与表结构定义缓存Cache
6.  表扫描缓存buffer
7.  MyISAM索引缓存buffer
8.  日志缓存
9.  预读机制
10. 延迟表与临时表

MySQL优化之缓存优化 (参考 [https://www.jb51.net/article/108173.htm][https_www.jb51.net_article_108173.htm])

MySQL的优化指的是一个很大的系统，面试的时候我之前是从sql的语句优化方面去说的，这种优化也有作用，不过是从逻辑方面去优化。但是当所有的逻辑层面已经无可优化，所有的索引都已经加好，表结构也设计的合理，但是遇到高并发的时候，为什么MySQL还是扛不住呢。当然可以通过其他的方面去缓解MySQL的压力，这里我们暂且不谈。对于MySQL而言，我们要尽最大的可能去压榨机器的性能，让所有的计算资源都不浪费，都可以为我们服务。MySQL运行在服务器上，这里特指Linux服务器。那么服务器的硬盘、CPU,内存，网络都有影响到MySQL的性能。MySQl是非常耗费内存的，线上服务器的MySQL内存要吃到80%左右，内存过小，其他的优化空间其实很小。

另外连接（connection）也是影响MySQL性能的重要一方面。MySQL客户机与MySQL服务器之间的连接是MySQL客户机与MySQL服务器反复握手的结果。每次'握手'都经历身份验证、权限验证等环节，握手需要占用一定的网络资源和MySQL服务器内存资源。

不得不提的是锁竞争，对于并发性能要求比较高的数据库而言，如果存在激烈的锁竞争，对数据库的性能将是很大的打击。锁竞争会明显的增加线程上下文切换的开销，这些开销都与预期的需求无关。

按照缓存读写功能的不同，MySQL将缓存分为Buffer缓存和Cache缓存。

Buffer缓存。由于硬盘的写入速度过慢，或者频繁的I/O，对于硬盘来说是极大的效率浪费。那么可以等到缓存中储存一定量的数据之后，一次性的写入到硬盘中。Buffer 缓存主要用于写数据，提升I/O性能。

Cache 缓存。 Cache 缓存一般是一些访问频繁但是变更较少的数据，如果Cache缓存已经存储满，则启用LRU算法，进行数据淘汰。淘汰掉最远未使用的数据，从而开辟新的存储空间。不过对于特大型的网站，依靠这种策略很难缓解高频率的读请求，一般会把访问非常频繁的数据静态化，直接由nginx返还给用户。程序和数据库I/O设备交互的越少，则效率越高。

\*优化MySQL时，一般会先[查看发送给mysql的查询语句][mysql]，然后运行[explain][]命令。稍加审查后很常见的做法是增加索引或者对模式做一些调整。一般情况下，我会建议用户先对MySQL进行优化，因为这是我认为开始阶段最合适的解决方案。但长期来看，大部分应用都会有一些用例需要一定程度上同时实现以上这些方案。(参考 优化MySQL，还是使用缓存？ [http://blog.jobbole.com/64998/][http_blog.jobbole.com_64998])

快慢查询 Commentary on MySQL slow query collection sources (参考 [http://www.tocker.ca/2013/11/21/commentary-on-mysql-slow-query-collection-sources.html][mysql])

### memcache ###

(参考 [https://blog.csdn.net/lxf2323881/article/details/79273465][https_blog.csdn.net_lxf2323881_article_details_79273465])

内存缓存技术：memcache是实现php语言 对内存 进行操作的中间介质。

**memcache与redis的区别和联系 **

**redis**:支持比较多的数据类型(String/list/set/sortset/hash)，redis支持**集合计算**的(set类型支持)，每个key最大数据存储量为1G，redis是新兴的内存缓存技术，对各方面支持不完善，支持**持久化**操作。

**memcache**：老牌的内存缓存技术，对相关领域支持比较丰富，window和linux都可以使用，各种框架(tp/yii等等)都支持使用，session的信息可以非常方便的保存到该memcache中，每个key保存的数据量最大为1M，支持的数据类型比较单一，就是**String**类型，不支持持久化。

**分布式**:把原先有一台memcache服务器做的工作，现在分摊到多台memcache执行。这样会降低memcache的工作负载。

**redis**:其为**主从模式**，一个redis负责数据写入，其他多个redis负责数据读取

**memcache**:其不是主从模式，该分布式是**平均分摊**工作，每个子服务器之间都是平级的，每个服务器都要执行数据的写入、读取操作。

两者的**相同之处在于把数据保存在内存中**。

**超过有效期**：具体是通过“懒惰”机制删除该过期数据，与过期session的删除类似。

过期session删除机制：session是以文件形式保存的硬盘中，如果有的session文件已经过期了，则该session文件不会立即被删除，而是后期其他用户访问网站使用session的同时会有一定的几率触发删除过期的session文件。

(session可以存入mysql数据库中。需求：**一个大型的网站开发完毕，内部涉及的服务器一般是有多个组成的，多台服务器彼此之间需要共享session信息，这样就要求session势必要存入mysql或memcache中。**session的信息以文件形式存储在服务器内部，不能实现多个服务器共享，只有存入的mysql或memcache中才可以实现数据共享。)

memcache的过期数据删除也是懒惰机制实现，如果有一个key过期了，其本身不会马上被删除，而是我们调用get方法获取数据的同时会删除该过期的数据。

**缓存空间耗尽 :** 如果存储的数据超过memcache最大的存储限制(默认是64M)，此时还继续存入数据，则会把最近不常使用的key就删除了。该机制名称为**[LRU][]**(least recently use)优先删除**最近很少使用**的key。

(参考 使用Memcache缓存mysql数据库操作的原理和缓存过程浅析[https://blog.csdn.net/liqfyiyi/article/details/50894027][https_blog.csdn.net_liqfyiyi_article_details_50894027])

1.首先明确是不是一定要上缓存，当前架构的瓶颈在哪里，若瓶颈真是数据库操作上，再继续往下看。

2.明确memcached和redis的区别，到底要使用哪个。**前者**终究是个缓存，**不可能永久保存数据（LRU机制）**，支持分布式，后者除了缓存的同时也支持把数据**持久化**到磁盘等，redis要自己去实现分布式缓存（貌似最新版本的已集成），自己去实现一致性hash。因为不知道你们的应用场景，不好说一定要用memcache还是redis，说不定用**mongodb**会更好，比如在**存储日志**方面。

3.缓存量大但又不常变化的数据，比如评论。

4.你的思路是对的，清晰明了，读DB前，先读缓存，如果有直接返回，如果没有再读DB，然后写入缓存层并返回。

(缓存更新流程：1、更新数据库 2、使缓存过期或失效，这样会促使下次查询数据时在缓存中查不到而重新从数据库去一次。     **通用缓存机制**：1、用查询的方法名+参数作为查询时的key value对中的key值 2、**向memcache或redis之类的NoSql数据库（或者内存hashmap）**插入数据 3、取数据时也用方法名+参数作为key向缓存数据源获取信息)

5.考虑是否需要主从，读写分离，考虑是否分布式部署，考虑是否后续水平伸缩。

6.想要一劳永逸，后续维护和扩展方便，那就将现有的代码架构优化，按你说的替换数据库组件需要改动大量代码，说明当前架构存在问题。可以利用现有的一些框架，比如SpringMVC，将你的应用层和业务层和数据库层解耦。在**上缓存之前把这些做好**。

7.把读取缓存等操作做成**服务组件**，对业务层提供服务，业务层对应用层提供服务。

8.保留原始数据库组件，优化成服务组件，方便后续业务层灵活调用缓存或者是数据库。  
9.不建议一次性全量上缓存，最开始不动核心业务，可以将边缘业务先换成缓存组件，一步步换至核心业务。  
10.刷新内存，以memcached为例，新增，修改和删除操作，一般采用**lazy load**的策略，即**新增时只写入数据库**，并不会马上更新Memcached，而是等到再次读取时才会加载到Memcached中，修改和删除操作也是更新 数据库，然后将Memcached中的数据标记为失效，等待下次读取时再加载。

> 当有Memcache中间缓存层时，查询的是Memcache缓存数据，下面详细了解Memcache各类数据操作原理：
> 
> 1. 查询数据(select)，首先通过指定的Key查询(get)Memcache中间缓存层数据，如果存在相对应数据，则直接获取出数据结果，查询过程完全不需要查询数据库。如果不存在，则查询MySQL数据库，并以key对应value的形式将查询结果存储在Memcache缓存数据中，然后将结果返回给查询语句。  
> 2. 更新数据(update)，首先更新数据，然后删除相关的memcache数据(delete)。  
> 3. 增加数据(add)，首先删除相关缓存数据，然后增加数据。  
> 4. 删除数据(delete)，删除数据，并删除Memcache数据。
> 
> 对MySQL的数据操作，主要涉及到的Memcache方法如下：
> 
> 1. 获取：get(key)  
> 2. 设置：set(key, value \[, expiry\])  
> 3. 删除：delete(key \[, time\])
> 
> Memcache基本操作过程
> 
> 1. 查询：$result = get($key.$id);如果$result为空，则查询MySQL数据库，然后set($key.$id,$value,0,$cachetime)  
> 2. 更新：delete($key.$id);  
> 3. 增加：delete($key.$id);  
> 4. 删除：delete($key.$id);

**前提：较少变更的数据才适合做缓存**

### **[如何用redis/memcache做Mysql缓存层][redis_memcache_Mysql]** ###

方法一：直接用Mysql  
**Mysql有缓存**，实现了类似的功能，如果需要缓存的东西很多，可以把缓存的内存设置大一点。  
这样的好处就是不用去控制缓存的失效，确保数据一致性。  
  
方法二：启用用DAO框架的缓存  
比如**Mybatis、Hibernate都是可以直接开启二级缓存**，一般是用ehcache作为实现，只要配置一下就行，无需额外操作。  
  
方法三：自行实现  
**用AOP去在Dao层做一个切面，把调用的“类名+方法名+参数”作为key，查询结果作为value，**每次调用去看一下是否已经缓存，如果没有再去调用Dao的实现类。  
注：如果真的要自行去实现，不建议做一个这么通用的方案，感觉重复造轮子。对性能要求极高的场景，可以根据实际需要做一些必要的缓存即可。

\*如何用redis/memcache做Mysql缓存层? ([https://www.zhihu.com/question/27738066][https_www.zhihu.com_question_27738066])

![20190429145530804.png][]

### 数据库分表策略 ###

参考  [数据库分库分表思路][Link 3] [https://www.cnblogs.com/butterfly100/p/9034281.html][Link 3] (用户中心的用户数据高频读低频写的问题一般用Redis来解决，能不分表分库就坚决不分表分库。 先尽量做索引、缓存、读写分离的优化，后期业务发展迅速，数据量到单表瓶颈时，再考虑分库分表)

MySQL 高可用：mysql+mycat实现数据库分片（分库分表）  [https://blog.csdn.net/kk185800961/article/details/51147029][https_blog.csdn.net_kk185800961_article_details_51147029] \[待学习\]

**一张表搞定100万记录，并且10G 数据库，如何快速分页！**答案就是：**复合索引**！

**（非分表策略 参考：**[https://mp.weixin.qq.com/s/iXmRCjwAf1gCYTZZguTIuw][https_mp.weixin.qq.com_s_iXmRCjwAf1gCYTZZguTIuw]**）**

**综上：如果对于有where 条件，又想走索引用limit的，必须设计一个索引，将where 放第一位，limit用到的主键放第2位，而且只能select 主键！**

### MVCC，Multi-Version Concurrency Control，多版本并发控制。 ###

如果有人从数据库中读数据的同时，有另外的人写入数据，有可能读数据的人会看到『半写』(幻读)或者不一致的数据(不可重复读)。有很多种方法来解决这个问题，叫做并发控制方法。最简单的方法，通过加锁，让所有的读者等待写者工作完成，但是这样效率会很差。MVCC 使用了一种不同的手段，每个连接到数据库的读者，**在某个瞬间看到的是数据库的一个快照**，写者写操作造成的变化在写操作完成之前（或者数据库事务提交之前）对于其他的读者来说是不可见的。

这种多版本的方式避免了填充删除操作在内存和磁盘存储结构造成的空洞的开销，但是需要系统周期性整理（sweep through）以真实删除老的、过时的数据。对于面向文档的数据库（Document-oriented database，也即半结构化数据库）来说，这种方式允许系统将整个文档写到磁盘的一块连续区域上，当需要更新的时候，直接重写一个版本，而不是对文档的某些比特位、分片切除，或者维护一个链式的、非连续的数据库结构。

**MVCC 提供了时点（point in time）一致性视图。**MVCC 并发控制下的读事务一般使用`时间戳`或者`事务 ID`去标记当前读的数据库的状态（版本），读取这个版本的数据。读、写事务相互隔离，不需要加锁。读写并存的时候，写操作会根据目前数据库的状态，创建一个新版本，并发的读则依旧访问旧版本的数据。

> 一句话讲，MVCC就是用 **`同一份数据临时保留多版本的方式`** 的方式，实现并发控制。
> 
> 这里留意到 MVCC 关键的两个点：
> 
> 1.  在读写并发的过程中如何实现多版本；
> 2.  在读写并发之后，如何实现旧版本的删除（毕竟很多时候只需要一份最新版的数据就够了

参考  [关于 MVCC 的基础][MVCC] [https://www.cnblogs.com/YFYkuner/p/5178684.html][MVCC]

## ##

### innodb和myisam区别  ###

[https://www.zhihu.com/question/20596402][https_www.zhihu.com_question_20596402]

数据库引擎简单来说就是一个"数据库**发动机"**(socket)。当你访问数据库时，不管是手工访问，还是程序访问，都不是直接读写数据库文件，而是通过数据库引擎去访问数据库文件。以关系型数据库为例，你发SQL语句给数据库引擎，数据库引擎解释SQL语句，提取出你需要的数据返回给你。因此，对访问者来说，数据库引擎就是SQL语句的解释器。  
  正式来说，数据库引擎是用于存储、处理和保护数据的核心服务。利用数据库引擎可以**控制访问权限并快速处理事务**，从而满足企业内大多数需要处理大量数据的应用程序的要求，这包括创建用于存储数据的表和用于查看、管理和保护数据安全的数据库对象(如索引、视图和存储过程)。(参考  [https://blog.csdn.net/gentelyang/article/details/80372045][https_blog.csdn.net_gentelyang_article_details_80372045] )

1、MyISAM：**默认表类型**，它是基于传统的ISAM类型，ISAM是Indexed Sequential Access Method **(有索引的顺序访问方法)** 的缩写，它是**存储记录和文件的标准方法**。**不是事务安全的，而且不支持外键，**如果执行大量的**select，insert** MyISAM比较适合。

2、InnoDB：**支持事务安全的引擎**，**支持外键、行锁、事务是他的最大特点**。如果有大量的**update和insert**，建议使用InnoDB，特别是针对多个并发和QPS较高的情况。([吞吐量（TPS）、QPS、并发数、响应时间（RT）概念][TPS_QPS_RT])

并发事务带来的几个问题：更新丢失，脏读，不可重复读，幻读。

事务隔离级别：未提交读(Read uncommitted)，已提交读(Read committed)，可重复读(Repeatable read)，可序列化(Serializable)

**Innodb的行锁模式**有以下几种：共享锁，排他锁，意向共享锁(表锁)，意向排他锁(表锁)，间隙锁。

注意：当语句没有使用索引，**innodb不能确定操作的行**，这个时候就使用的**意向锁，也就是表锁**

参考 [https://www.cnblogs.com/y-rong/p/8110596.html][https_www.cnblogs.com_y-rong_p_8110596.html]

**MyISAM ：**myisam属于堆表

**InnoDB ：**innodb属于索引组织表

innodb有两种存储方式，共享表空间存储和多表空间存储

**\*\*开发的注意事项**

<table> 
 <tbody> 
 <tr> 
 <td> 1、可以用 show create table tablename 命令看表的引擎类型。 2、对不支持事务的表做start/commit操作没有任何效果，在执行commit前已经提交。 3、可以执行以下命令来切换非事务表到事务（数据不会丢失），innodb表比myisam表更安全：alter table tablename type=innodb;或者使用 alter table tablename engine = innodb; 4、默认innodb是开启自动提交的，如果你按照myisam的使用方法来编写代码页不会存在错误，只是性能会很低。如何在编写代码时候提高数据库性能呢？ a、尽量将多个语句绑到一个事务中，进行提交，避免多次提交导致的数据库开销。 b、在一个事务获得排他锁或者意向排他锁以后，如果后面还有需要处理的sql语句，在这两条或者多条sql语句之间程序应尽量少的进行逻辑运算和处理，减少锁的时间。 c、尽量避免死锁 d、sql语句如果有where子句一定要使用索引，尽量避免获取意向排他锁。 f、针对我们自己的数据库环境，日志系统是直插入，不修改的，所以我们使用混合引擎方式，ZION_LOG_DB照旧使用myisam存储引擎，只有ZION_GAME_DB，ZION_LOGIN_DB，DAUM_BILLING使用Innodb引擎。 </td> 
 </tr> 
 </tbody> 
</table>

**\*\*究竟该怎么选择**    
**myisam只有索引缓存     
innodb不分索引文件数据文件 innodb buffer   **

<table> 
 <tbody> 
 <tr> 
 <td> myisam只能管理索引，在索引数据大于分配的资源时，会由操作系统来cache；数据文件依赖于操作系统的cache。innodb不管是索引还是数据，都是自己来管理&nbsp;&nbsp; 思考上面这些问题可以让你找到合适的方向，但那并不是绝对的。如果你需要事务处理或是外键，那么InnoDB 可能是比较好的方式。如果你需要全文索引，那么通常来说 MyISAM是好的选择，因为这是系统内建的，然而，我们其实并不会经常地去测试两百万行记录。所以，就算是慢一点，我们可以通过使用Sphinx从InnoDB中获得全文索引。&nbsp;&nbsp; 数据的大小，是一个影响你选择什么样存储引擎的重要因素，大尺寸的数据集趋向于选择InnoDB方式，因为其支持事务处理和故障恢复。数据库的大小决定了故障恢复的时间长短，<a href="https://www.cnblogs.com/java-jun-world2099/p/9290966.html" rel="nofollow">InnoDB可以利用事务日志进行数据恢复</a>，这会比较快。而MyISAM可能会需要几个小时甚至几天来干这些事，InnoDB只需要几分钟。&nbsp;&nbsp; 操作数据库表的习惯可能也会是一个对性能影响很大的因素。比如： COUNT() 在 MyISAM 表中会非常快，而在InnoDB 表下可能会很痛苦。而主键查询则在InnoDB下会相当相当的快，但需要小心的是如果我们的主键太长了也会导致性能问题。大批的inserts 语句在 MyISAM下会快一些，但是updates 在InnoDB下会更快一些——尤其在并发量大的时候。&nbsp;&nbsp; 所以，到底你检使用哪一个呢？根据经验来看，如果是一些小型的应用或项目，那么MyISAM 也许会更适合。当然，在大型的环境下使用 MyISAM 也会有很大成功的时候，但却不总是这样的。如果你正在计划使用一个超大数据量的项目，而且需要事务处理或外键支持，那么你真的应该直接使用 InnoDB方式。但需要记住InnoDB 的表需要更多的内存和存储，转换100GB 的MyISAM 表到InnoDB 表可能会让你有非常坏的体验。&nbsp;&nbsp; 对于支持事务的InnoDB类型的表，影响速度的主要原因是AUTOCOMMIT默认设置是打开的，而且程序没有显式调用BEGIN 开始事务，导致每插入一条都自动Commit，严重影响了速度。可以在执行sql前调用begin，多条sql形成一个事务（即使autocommit打开也可以），将大大提高性能。&nbsp;&nbsp; &nbsp; MyISAM适合：(1)做很多count 的计算；(2)插入不频繁，查询非常频繁；(3)没有事务。 InnoDB适合：(1)可靠性要求比较高，或者要求事务；(2)表更新和查询都相当的频繁，并且行锁定的机会比较大的情况。 3. 系统奔溃后，MyISAM恢复起来更困难，能否接受； 4. MySQL5.5版本开始Innodb已经成为Mysql的默认引擎(之前是MyISAM) </td> 
 </tr> 
 </tbody> 
</table>

InnoDB

InnoDB 给 MySQL 提供了具有事务(commit)、回滚(rollback)和崩溃修复能力 (crash recovery capabilities)的事务安全(transaction-safe (ACID compliant))型表。 InnoDB 提供了行锁(locking on row level)，提供与 Oracle 类型一致的不加锁读取(non- locking read in SELECTs)。这些特性均提高了多用户并发操作的性能表现。在InnoDB表中不需要扩大锁定 (lock escalation)，因为 InnoDB 的列锁定(row level locks)适宜非常小的空间。 InnoDB 是 MySQL 上第一个提供外键约束(FOREIGN KEY constraints)的表引擎。    
  
InnoDB 的设计目标是处理大容量数据库系统，它的 CPU 利用率是其它基于磁盘的关系数据库引擎所不能比的。在**技术上**，InnoDB 是一套放在 MySQL 后台的完整数据库系统，**InnoDB 在主内存中建立其专用的缓冲池用于高速缓冲数据和索引**。 InnoDB 把数据和索引存放在表空间里，可能包含多个文件，这与其它的不一样，举例来说，在 MyISAM 中，表被存放在单独的文件中。InnoDB 表的大小只受限于操作系统的文件大小，一般为 2 GB。    
InnoDB所有的表都保存在同一个数据文件 ibdata1 中（也可能是多个文件，或者是独立的表空间文件）,相对来说比较不好备份，免费的方案可以是拷贝数据文件、备份 binlog，或者用 mysqldump。

MyISAM     
MyISAM 是MySQL缺省存贮引擎 .     
每张MyISAM 表被存放在三个文件 。frm 文件存放表格定义。 数据文件是MYD (MYData) 。 索引文件是 MYI (MYIndex) 引伸。     
因为MyISAM相对简单所以在效率上要优于InnoDB..小型应用使用MyISAM是不错的选择.     
MyISAM表是保存成文件的形式,在跨平台的数据转移中使用MyISAM存储会省去不少的麻烦     
    
以下是一些细节和具体实现的差别：     
    
1.InnoDB不支持FULLTEXT类型的索引。     
2.InnoDB 中不保存表的具体行数，也就是说，执行select count(\*) from table时，InnoDB要扫描一遍整个表来计算有多少行，但是MyISAM只要简单的读出保存好的行数即可。注意的是，当count(\*)语句包含 where条件时，两种表的操作是一样的。    
3.对于AUTO\_INCREMENT类型的字段，InnoDB中必须包含只有该字段的索引，但是在MyISAM表中，可以和其他字段一起建立联合索引。     
4.DELETE FROM table时，InnoDB不会重新建立表，而是一行一行的删除。     
5.[LOAD TABLE FROM MASTER][]操作对InnoDB是不起作用的，解决方法是首先把InnoDB表改成MyISAM表，导入数据后再改成InnoDB表，但是对于使用的额外的InnoDB特性（例如外键）的表不适用。  \[已弃用\]  
  
另外，InnoDB表的行锁也不是绝对的，如果在执行一个SQL语句时MySQL不能确定要扫描的范围，InnoDB表同样会锁全表，例如 update table set num=1 where name**like** “%aaa%”    
  
任何一种表都不是万能的，只用恰当的针对业务类型来选择合适的表类型，才能最大的发挥MySQL的性能优势。

插一句用MySQL而不用oracle的原因 :(参考  [https://bbs.csdn.net/topics/391954245][Oracle_MySQL])

可以想象，每年双11，Oracle都派人驻场进行技术支持，但始终会因为阿里未能掌握Oracle的技术底层核心实现，会导致出现无法对潜在问题的风险、影响范围等进行有效的评估和预案准备；若问题发生后，阿里也无法及时有效的解决，只能完全依赖Oracle团队的技术支持，很容易会出现“船上人不得力，坎上人挣断腰”的尴尬局面。跨部门协调尚且会有部门墙存在，跨公司合作各种商务沟通，对内对外协调会更加困难。...

单纯从表的数据量而言，MySQL的最佳实践建议是单表百万级，控制在千万级内；而Oracle单表可以千万级甚至亿级也没太大问题。而且，MySQL从一开始的设计目标便不是为了追求强一致性事务，这导致MySQL的可靠性和事务性方面就完全和Oracle不在一个可比较的级数。应只把最核心，同时非常强调数据一致性的强事务类的业务放在Oracle上，用好NoSQL和分布式缓存，降低核心Oracle数据库的负载压力。...

### 关于死锁： ###

什么是死锁？当两个事务都需要获得对方持有的排他锁才能完成事务，这样就导致了循环锁等待，也就是常见的死锁类型。

解决死锁的方法：

1、  数据库参数

2、  应用中尽量约定程序读取表的顺序一样

3、  应用中处理一个表时，尽量对处理的顺序排序

4、  调整事务隔离级别（避免两个事务同时操作一行不存在的数据，容易发生死锁）

[Link 1]: https://mp.weixin.qq.com/s/FwGZVw5UbqEcbtld0pf9tA
[Oracle_MySQL]: https://bbs.csdn.net/topics/391954245
[SQL_]: https://www.cnblogs.com/yunfeifei/p/3850440.html
[MySQL]: https://baijiahao.baidu.com/s?id=1617888740370098866&wfr=spider&for=pc
[20190322213040698.png]: /images/20220303/c5a00f6a984341549e8fe0dbba31629b.png
[MySQL_Binary Log]: https://www.cnblogs.com/joemsu/p/8868300.html
[Link 2]: https://dev.mysql.com/doc/refman/5.7/en/point-in-time-recovery.html
[https_www.jb51.net_article_108177.htm]: https://www.jb51.net/article/108177.htm
[https_www.jb51.net_article_108173.htm]: https://www.jb51.net/article/108173.htm
[mysql]: http://www.tocker.ca/2013/11/21/commentary-on-mysql-slow-query-collection-sources.html
[explain]: http://www.tocker.ca/2013/05/29/optimizing-in-subqueries-in-mysql-56.html
[http_blog.jobbole.com_64998]: http://blog.jobbole.com/64998/
[https_blog.csdn.net_lxf2323881_article_details_79273465]: https://blog.csdn.net/lxf2323881/article/details/79273465
[LRU]: https://blog.csdn.net/weixin_39593985/article/details/88538363
[https_blog.csdn.net_liqfyiyi_article_details_50894027]: https://blog.csdn.net/liqfyiyi/article/details/50894027
[redis_memcache_Mysql]: https://www.cnblogs.com/hellowzd/p/5163768.html
[https_www.zhihu.com_question_27738066]: https://www.zhihu.com/question/27738066
[20190429145530804.png]: /images/20220303/79f69675d1b2488b876e58df7ca320ad.png
[Link 3]: https://www.cnblogs.com/butterfly100/p/9034281.html
[https_blog.csdn.net_kk185800961_article_details_51147029]: https://blog.csdn.net/kk185800961/article/details/51147029
[https_mp.weixin.qq.com_s_iXmRCjwAf1gCYTZZguTIuw]: https://mp.weixin.qq.com/s/iXmRCjwAf1gCYTZZguTIuw
[MVCC]: https://www.cnblogs.com/YFYkuner/p/5178684.html
[https_www.zhihu.com_question_20596402]: https://www.zhihu.com/question/20596402
[https_blog.csdn.net_gentelyang_article_details_80372045]: https://blog.csdn.net/gentelyang/article/details/80372045
[TPS_QPS_RT]: https://www.cnblogs.com/data2value/p/6220859.html
[https_www.cnblogs.com_y-rong_p_8110596.html]: https://www.cnblogs.com/y-rong/p/8110596.html
[LOAD TABLE FROM MASTER]: https://blog.csdn.net/yejinxiong001/article/details/50906021