锁
- 通常分为两种锁，一是共享锁（读锁），一种是排他锁（写锁）。读锁是共享的，或者说是互相不阻塞的。多个客户在同一时刻可以同时读取同一个资源而互不干扰。写锁则是排他的，也就是说写锁会阻塞其他的读锁和写锁。
- MySQL中主要有两种锁：表锁（table lock）和行级锁（row lock）
- 死锁的概念：多个线程因竞争系统资源或相互通信而处于永久阻塞状态，若无外力作用，这些线程都将无法继续向前推进。这些线程中的每一个线程都无限期的等待此组进程中某个其他线程占有的、自己永远无法得到的资源，这种现象称为死锁。
表锁
是MySQL中最基本的锁策略，并且是开销最小的策略。表锁会锁定整张表。一个用户在对表进行写操作（插入、删除、更新）之前，必须先获得写锁，这会阻塞其他用户对该表的所有读写操作。只有在没有写锁的情况下，其它读取的用户才能获得读锁，读锁之间是不会互相阻塞的。此外，写锁的优先级是高于读锁的，因此一个写锁请求可能会插入到读锁队列的前面（读锁不可能插入到写锁的前面）。
行级锁
行级锁可以最大程度地支持并发处理（同时也带来了最大的锁开销）。行级锁只锁定单独的一行，这样其他的用户就可以正常访问其他的行，提升了并发度。
事务处理
- 什么叫事务处理
事务处理可以用来维护数据库的完整性，以保证数据库不包含不完整的操作结果。利用事务处理，可以保证一组操作不会中途停止，他们或者作为整体执行，或者完全不执行，如果没有错误发生，整组语句提交给数据库表，如果发生错误，则进行回退，以恢复数据库到某个已知且安全的状态。支持事务的数据库必须具备以下四个特性：
原子性
原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚，因此事务的操作如果成功就必须要完全应用到数据库，如果操作失败则不能对数据库有任何影响。
一致性
一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。
隔离性
隔离性是当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。即要达到这么一种效果：对于任意两个并发的事务T1和T2，在事务T1看来，T2要么在T1开始之前就已经结束，要么在T1结束之后才开始，这样每个事务都感觉不到有其他事务在并发地执行。 若不提供事务的隔离性，可能会导致数据的脏读，不可重复读和幻读
持久性
持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。
MySQL提供的四种隔离级别：
- Serializable (串行化)：可避免脏读、不可重复读、幻读的发生。
- Repeatable read (可重复读)：可避免脏读、不可重复读的发生。
- Read committed (读已提交)：可避免脏读的发生。
- Read uncommitted (读未提交)：最低级别，任何情况都无法保证。
Note: REPEATABLE READ解决了脏读问题，该级别保证了在同一个事务中多次读取同样的记录的结果是一致的。但是无法解决幻读问题，幻读是指当某个事务在读取某个范围内的记录时，另外一个事务又在该范围内插入了新的记录，当之前的记录再次读取该范围的记录时会产生幻行。InnoDB存储引擎通过MVCC（多版本并发控制）解决了幻读问题。该隔离级别是MySQL的默认隔离级别。
以上四种隔离级别最高的是Serializable级别，最低的是Read uncommitted级别，当然级别越高，执行效率就越低。像Serializable这样的级别，就是以锁表的方式(类似于Java多线程中的锁)使得其他的线程只能在锁外等待，所以平时选用何种隔离级别应该根据实际情况。在MySQL数据库中默认的隔离级别为Repeatable read (可重复读)。
多版本并发控制(MVCC)
- MVCC是行级锁的一个变种，它在很多情况西安避免了加锁操作，因此开销更低，MVCC大都实现了非阻塞的读操作，写操作也只是锁定必要的行
InnoDB的MVCC是通过在每行记录后面保存两个隐藏的列来实现的。这两个列，一个保存了行的创建时间，一个保存行的过期时间（删除时间），但是存储的并不是实际的时间值，而是系统版本号。每开始一个新的事务，系统版本号都会自动递增。事务开始时刻的版本号作为事务的版本号。
MVCC具体操作
SELECT:
a、InnoDB只查找版本号早于当前事务的数据行（也就是说，行的系统版本号小于或等于事务的系统版本号），这样确保了事务读取的行，要么在事务开始之前就已经存在，要么就是事务自身插入或者修改的数据（这就解决了幻读问题）。
b、行的删除版本（也就是过期时间），要么未定义，要么大于当前事务版本号。这样可以保证事务读取的行在事务开始之前没有被删除。
INSERT:
InnoDB为新插入的每一行保存当前系统版本号作为行版本号。
DELETE:
InnoDB为删除的每一行保存当前系统版本号作为行删除版本号。
UPDATE:
InnoDB为插入的一行新纪录保存当前系统版本号作为行版本号，同时保存当前系统版本号到原来的行作为行删除版本号。
这样做可以使得大多数读操作都可以不用加锁，读操作性能很好，并且保证只会读到符合标准的行。缺点就是，需要额外的存储空间，做更多的行检查，以及额外的维护工作。
InnoDB和MyISAM存储引擎的区别
InnoDB:是MySQL的默认事务型引擎，也是最重要的、使用最广泛的存储引擎。其用于处理大量的短期事务，短期事务大部分情况下是正常提交的，很少会被回滚。
InnoDB的数据存储在表空间中，表空间是由InnoDB管理的一个黑盒子，由一系列数据文件组成。InnoDB采用MVCC支持高并发，并且实现了四个标准的隔离级别。其通过间隙锁策略防止幻读的出现。间隙锁使得InnoDB不仅仅锁定查询所涉及的行，还会对索引中间隙进行锁定，以防止幻影行的插入。
InnoDB表是基于聚簇索引建立的。聚簇索引对主键查询性能很高，不过二级索引中必须包含主键列，所以如果主键列很大的话，其他的所有索引都会很大。
此外，InnoDB支持真正的热备份，MySQL的其它存储引擎都不支持热备份。 note:热备份是指在数据库正常运行的情况下，进行备份，而冷备份是指定期的关闭服务器来进行备份
MyISAM: MyISAM提供了大量的特性，包括全文索引、压缩、空间函数等，但MyISAM不支持事务和行级锁，而且一大缺陷就是崩溃后无法安全恢复。MyISAM会将表存储在两个文件中，数据文件和索引文件。
MyISAM会对整张表加锁。读取时会对需要读到的所有表加共享锁。写入时则对表加排他锁。对于MyISAM表，MySQL可以手工或者自动执行检查和修复操作，但是这与事务恢复和崩溃恢复是不同的，执行表的修复可能会导致一些数据丢失，而且修复操作是非常缓慢的。
- 区别：
- InnoDB不支持全文索引，而MyISAM支持。InnoDB支持聚簇索引，而MyISAM不支持。
- InnoDB中不保存表的具体行数，而MyISAM中保存有表的具体行数，也就是说，执行select count() from table时，InnoDB要扫描一遍整个表来计算有多少行，但是MyISAM只要简单的读出保存好的行数即可。注意的是，当count()语句包含 where条件时，两种表的操作是一样的，都要扫描一遍整个表。
- MyISAM是非事务安全型的，而InnoDB是事务安全型的
- MyISAM锁的粒度是表级，而InnoDB支持行级锁定
- MyISAM相对简单，所以在效率上要由于InnoDB,小型应用可以考虑使用MyISAM
- InnoDB比MyISAM更安全，MyISAM在崩溃之后无法安全恢复，而InnoDB在自动崩溃之后可以进行恢复
- 对于AUTO_INCREMENT类型的字段，InnoDB中必须包含只有该字段的索引，但是在MyISAM表中，可以和其他字段一起建立联合索引。
- DELETE FROM table时，InnoDB不会重新建立表，而是一行一行的删除。MyISAM则会重新建立一张表格，并将剩余的行（不需要删除的行）复制到该表格里面，返回该表。
- LOAD TABLE FROM MASTER操作对InnoDB是不起作用的，解决方法是首先把InnoDB表改成MyISAM表，导入数据后再改成InnoDB表，但是对于使用的额外的InnoDB特性(例如外键)的表不适用。 另外，InnoDB表的行锁也不是绝对的，假如在执行一个SQL语句时MySQL不能确定要扫描的范围，InnoDB表同样会锁全表，例如update table set num=1 where name like “%aaa%”