MySQL高性能数据_第三版(读书笔记)

1. 如何保证在系统崩溃时，事务处理的数据一致性？（事务日志）

概念：事务日志可以帮助提升事务的效率。

使用事务日志，存储引擎在修改表的数据时只需要修改其内存拷贝，再把该修改行为记录到持久在硬盘上的事务日志中，而不用每次都将修改的数据本身持久到磁盘。

事务日志采用的是追加的方式，因此写日志的操作是磁盘上一小块区域内的顺序I/O，而不像随机I/O需要在磁盘的多个地方移动磁头，所以采用事务日志的方式相对来说要快的多。

事务日志持久以后，内存被修改的数据在后台可以慢慢的刷回到磁盘。目前大多数存储引擎都是这样是实现的，我们通常称之为预写式日志（Write-Ahead Logging），修改数据需要写两次磁盘。

保持一致性：如果数据的修改已经记录到事务日志并持久化，但数据本身还没有写回磁盘，此时系统崩溃，存储引擎再重启时能够自动回复这部分修改的数据。具体的回复方式则视存储引擎决定。

InnoDB用事务日志把随机I/O变成顺序I/O。

InnoDB的日志是环形方式写的：当写到日志的尾部，会重新跳转到开头继续写，但不会覆盖还没有应用到数据文件的日志记录。

InnoDB使用一个后台线程智能地刷新这个日志变更到数据文件。

整体的日志文件大小受控于innodb_log_file_size和innodb_log_files_in_group两个参数，这对写性能非常重要。

2. InnoDB怎么刷新日志缓冲？

当InnoDB把日志缓冲刷新到磁盘日志文件时，会先使用一个Mutex锁（互斥锁）锁住缓冲区，刷新到所需要的位置，然后移动剩下的条目到缓冲区的前面。当Mutex释放时，可能有超过一个事务已经准备好刷新其日志记录。InnoDB有一个Group Commit功能，可以再一个I/O操作内提交多个事务。日志缓冲必须被刷新到持久化存储中，已确保提交的事务完全被持久化了。

3. 在事务中混合使用存储引擎？

支持事务：InnoDB、NDB Cluster

不支持事务：MyISAM

MySQL服务器不管理事务，事务是由下层的存储引擎实现的，所以最好不要在一个事务中使用多种数据引擎。比如在事务中混合使用InnoDB和MyISAM表，如果事务需要回滚，则使用InnoDB的表会正常回滚，但是MyISAM表不会正常回滚，导致数据的不一致性。

在非事务型的表中执行事务相关操作是，MySQL不会发出任何提醒及报错，只有回滚的是会发出警告："某些非事务型的表上的更改不能被回滚”。

4. 隐式和显式的锁定

InnoDB采用的是两阶段锁定协议(two-phase locking protocol)。

隐式锁定：在事务执行过程中，随时都可以执行锁定，锁只有在执行COMMIT和ROLLBACK的时候才会释放，并且所有的锁都是在同一时刻被释放。InnoDB会根据隔离级别在需要的时候自动加锁。

显式锁定：比如：SELECT ... LCOK IN SHARE MODE ; SELECT ... FOR UPDATE

MySQL也支持LOCK TABLES和UNLOCK TABLES语句，但这是在服务层实现的，和存储引擎无关，不能代替事务处理。

5. 多版本并发控制(MVCC)

MySQL的大多数事务型存储引擎都不是简单地行级锁。基于提升并发性能的考虑，都同时实现了多版本并发控制MVCC。

MVCC的实现，是通过保存数据在某个时间点的快照来实现的。也就是说，不管需要执行多长时间，每个事务看到的数据都是一致的。根据事务开始的时间不同，每个事务对同一张表，同一时刻看到的数据可能是不一样的。

MVCC只在REPEATABLE READ(可重复读)和READ COMMITTED(提交读) 两个隔离级别下工作。其它两个隔离级别和MVCC不兼容，因为READ UNCOMMITTED总是读取最新的数据行，而不是符合当前事务版本的数据行，而SERIALIAZBLE则会对所有读取的行都加锁。

6. InnoDB的MVCC的实现

InnoDB的MVCC，是通过在每行记录后面保存两个隐藏的列来实现的。这两个列，一个保存行的创建时间，一个保存行的删除时间。这里的时间不是真实的时间而是系统版本号。每开始一个新的事务，系统版本号都会自动递增。事务开始时刻的系统版本号会作为事务的版本号，用来查询到的每行记录的版本号。

7. 在REPEATABLE READ(可重复读)默认隔离级别下，MVCC如何运行

SELECT

InnoDB会根据以下两个条件检查每行记录：

a.InnDB只查找版本早于当前事务版本的数据行（也就是说，行的系统版本号小于或等于事务的系统版本号），这样可以确保事务读取的行，要么是在事务开始的已经存在的，要么是事务自身插入或者修改过的。

b.行的删除版本要么未定义，要么大于当前事务版本号。这可以确保事务读取到的行，在事务开始之前未被删除。

只有符合上述的两个条件的记录，才能返回作为查询结果。

INSERT

InnoDB为新插入的每一行保存当前系统版本号作为行版本号。

DELETE

InnoDB未删除每一行保存当前系统版本号作为行删除标识。

UPDATE

InnoDB为插入一行新纪录，保存当前系统版本号作为行版本号，同时保存当前系统版本号到原来的行作为行删除标识。

8. InnoDB概览

a. InnoDB采用MVCC来支持高并发，并且实现了四个标准的隔离级别。其默认级别是REPEATABLE READ（可重复读），并且通过间隙锁（next-key locking）策略防止幻读的出现。间隙锁不仅仅锁定查询涉及的行，还会对索引中的间隙进行锁定，以防止幻影行的插入。

b.InnoDB表是基于聚簇索引建立的。聚簇索引对于主键查询有很高的性能，不过它的二级索引（secondary index，非主键索引）中必须包含主键列，所以如果主键列很大的话个，其它的所有索引都会很大。因此，若表上的索引较多的话，主键应当尽可能的小。

c.强烈建议阅读官方手册中的"InnoDB事务模型和锁"一节

9. MySQL数据类型

整数类型

TINYINT、SMALLINT、MEDIUMINT、INT、BIGINT 分别使用8、16、24、32、64位存储空间。可以存储的值的范围从 $-2^{^{N-1}}$ 到 $2^{N-1}-1$ ，其中N是存储空间的位数。

整数类型有可选的UNSIGNEN属性，表示不允许负值，这大致可以是正数的上限提高一倍。

有符号和无符合类型使用相同的存储空间，具有相同的性能。

MySQL可以为整数指定宽度，例如INT(11)，对大多数应用是没有意义的：它不会限制值的合法范围，只是规定了如MySQL的一些交互工具用来显示字符的个数。对于存储和计算来说，INT(1)和INT(20)是相同的。

实数类型

MySQL5.0和更高版本将数字打包保存到一个二进制字符串中，每4个字节存9个数字。

DECIMAL(19,9)：小数部分具有9个数字，占用4个字节；整数部分具有10个数字，占用4+1=5个字节；小数点占用1个字节；一共占用10个字节。

VARCHAR和CHAR

VARCHAR：存储可变长字符串；需要1-2个额外字节记录字符串的长度。

使用VARCHAR(5)和VARCHAR(200)储存‘hello’的空间开销是一样的，但是更长的列会消耗更多的内存，因为MySQL通常会分配固定大小的内存块来保存内部值。尤其是使用内存临时表进行排序或者操作是特别糟糕。

CHAR：存储定长字符串。

BLOB和TEXT

BLOB：存储大数据而设计的字符串数据类型；二进制存储；没有排序规则或字符集。

TEXT：存储大数据而设计的字符串数据类型；字符串存储；有排序规则和字符集。

BLOB和TEXT：排序只对每个列的最前max_sort_length字节而不是整个字符串排序，可以配置该max_sort_length，或者使用order by substring(column,length)

日期时间类型

DATETIME：存储1001~9999年，精度为秒；它把日期和格式封装到格式为YYYYMMDDHHMMSS的整数中，与时区无关，使用8个字节存储。

TIMESTAMP：存储1970年1月1日午夜（格林尼治标准时间）以来的秒数~2038年，和UNIX的时间戳相同；与当前系统时区有关；使用4个字节的存储空间。

⭐️如果要存储微妙级别的时间戳，1️⃣使用double存储秒之后的小数部分、2️⃣使用bigint类型存储

10. 为什么MySQL不应设计字段太多的宽表

MySQL的存储引擎API工作时需要在服务器层和存储引擎层之间通过行缓冲格式拷贝数据，然后在服务器层将缓冲内容解码成各个列。从行缓冲中将编码过的列转换成行数据结构操作代价非常高，转换的代价依赖于列的数量，所以不应设计宽表。

11. 索引

MySQL中索引是在存储引擎层实现的，而不是在服务器层。

优点：

a>>大大减少了服务器需要扫描的数据量，提高查询效率。

b>>帮助服务器避免排序和临时表。

c>>将随机I/O转变为顺序I/O

12. 自适应哈希索引

InnoDB存储引擎有一个特殊的功能叫做”自适应哈希索引“，当InnoDB注意到某些索引值被使用的非常频繁时，它会在内存中基于B+Tree索引之上再创建一个哈希索引，这样就让B+Tree索引也具有哈希索引的一些优点，比如快速的哈希查找。但这是一个完全自动、内部的行为，用户无法控制或者配置，但可以关闭该功能。

13. 聚簇索引

InnoDB默认使用聚簇索引，被索引的列为主键列；如果没有定义主键，则选择一个唯一的非空索引代替；否则会隐式定义一个主键来作为聚簇索引。

聚簇索引的每一个叶子结点都包含了主键值、事务ID、用于事务和MVCC的回滚指针以及所有的剩余列

优点：

a>>可以将相关连的数据保存在一起。

b>>数据访问速度更快。因为索引和数据保存在同一个B-Tree中

c>>使用覆盖索引扫描的查询可以直接使用叶节点中的主键值。

缺点：

a>>插入的速度严重依赖插入顺序。按照主键的顺序插入是加载数据到InnoDB表中速度最快的方式。使用OPTIMIZE TABLE命令重新组织一下表。

b>>更新聚簇索引列的代价很高。该操作会强制InnoDB将每个被更新的行移动到新的位置。

c>>基于聚簇索引的表在插入新行，或者主键被更新导致需要移动行的时候，可能面临”页分裂“的问题。页分裂会导致表占用更多的磁盘空间。

d>>聚簇索引可能导致全表扫描变慢，尤其是行比较稀疏，或者由于页分裂导致数据存储不连续的时候。

e>>二级索引（非聚簇索引）占用空间更大。因为叶子结点中包含了引用行的主键列。

f>>二级索引访问需要两次索引查找而不是一次。二级索引中存储的不是指向行的物理位置的指针，而是行的主键值，这样的策略减少了当出现航移动或者数据页分裂时二级索引的维护工作。

14. 为什么InnoDB引擎下最好使用自增id作为主键？

优点：

在InnoDB引擎下使用自增ID作为主键的情况下，比使用uuid或者自定义列作为主键，插入的速度要快。因为InnoDB默认是主键聚簇索引，实际的主键值必须要按照逐渐顺序存取，自增ID本身就是有顺序的，所以在插入数据时，底层就不必再进行排序操作，也减少了索引页分裂的次数，从而大大增加了insert的速度，查询亦然。

innodb_auroinc_lock_mode：控制InnoDB如何生成自增主键值，

缺点：

并发插入可能导致间隙锁竞争。解决办法可以重新设计表或者修改innodb_autoinc_lock_mode配置。

15. 存储引擎

a>>并不是所有的非聚簇索引都能做到一次索引查询就找到行，当行更新的时候可能无法存储在原来的位置，这会导致表中出现行的碎片化或者移动行并在原位置保存”向前指针“，这两种情况都会导致在查找行时需要更多的工作。

b>>InnoDB在二级索引上使用共享锁（读锁），但访问主键索引需要排它锁（写锁）。这消除了使用覆盖索引的可能性，并且是的SELECT FOR UDPATE 比 LOCK IN SHARE MODE 或非锁定查询要慢很多。

16.服务器层

a>>如果是所有存储引擎共有的特性则由服务器层实现，比如时间和日期函数、视图、触发器等。

17. 索引和锁

索引可以让查询锁定更少的行。如果你的查询不访问不需要的行，那么就会锁定更少的行，对性能有好处。其次，锁定超过需要的行会增加锁争用并减少并发性。

InnoDB只有在访问行的时候才会对其加锁，而索引能够减少InnoDB访问的行数，从而减少锁的数量。但是只有当InnoDB在存储引擎层能够过滤掉所有不需要的行时才会有效，如果索引无法过滤掉无效的行，那么在InnoDB检索到数据并返回服务器层之后，MySQL服务器才能应用Where子句，这时候已经无法避免锁定行了，InnoDB已经锁住了这些行，只有事务提交后才会释放锁，但在MySQL5.1及更新版本中，InnoDB可以在服务端过滤掉行后就释放锁。

18. Using where和Using index

SELECT actor_id from tb_actor where actor_id<5 and actor_id!=1 for udpate;

查询会返回actor_id在2~4之间的行，但是实际上获取了1~4之间的行排它锁，InnoDB会锁住第1行。

底层存储器的操作是”从索引的开头开始获取满足条件actor_id<5 的记录“，服务器并没有告诉InnoDB可以过滤第一行的WHERE条件。EXPLAIN 的Extra列出现了”Using where“：表示MySQL服务器将存储引擎返回行以后再应用Where过滤条件。

19. MySQL应用WHERE条件的方式

a 好>>在索引中使用WHERE条件来过滤不匹配的记录，在存储引擎层完成。

b 中>>使用索引覆盖扫描（在Extra列中出现了Using Index）来返回记录，直接从索引中过滤不需要的记录并返回命中结果。在MySQL服务器层完成，无需回表查询数据。

c 差>>从数据表中返回数据，然后过滤不满足条件的记录（在Extra列中出现Using Where），在MySQL服务器层完成，先从数据表中读出记录然后过滤。

20. MySQL的执行查询方式

MySQL总是从一个表开始一直嵌套循环、回溯完成所有表关关联。所以MySQL的执行计划是一棵左侧深度优先的树。

21. MySQL的查询排序

情况一：如果order by子句中的所有列都是来自关联的第一个表

>> MySQL在关联处理第一个表的时候就进行文件排序，Explain结果中可以看到Extra字段"Using filesort"

情况二：不都是来自于关联的第一个表

>> MySQL会将关联的结果存放到一个临时表中，然后再所有的关联都结束后，再进行文件排序。Explain结果中可以看到Extra字段"Using temporary；Using filesort"

22. MySQL如何返回结果给客户端

a>>即使查询不到需要返回结果集给客户端，MySQL仍然会返回这个查询的一些信息，比如该查询影响到的行数。

b>>如果查询可以被缓存，则在这个阶段将结果存放到查询缓存中。

c>>将结果集返回客户端是一个增量、逐步返回的过程。一旦服务器处理完最后一个关联表，开始生成第一条结果时，MySQL就开始向客户端逐步返回结果集。好处：服务器端无须存储太多的结果，也就不会因为要返回太多结果而消耗太多内存。另外这样的处理也让MySQL客户端第一时间获得返回的结果。

23. MyISAM存储引擎下COUNT()函数

MyISAM函数计算很快的前提条件是：没有任何WHERE条件的COUNT(*)，可以直接获取这个值。

当统计带WHERE子句的结果集行数时，MyISAM的COUNT()函数和其它存储引擎没有什么不用。

24. 分区表的限制条件

a>> 一个表最多有1024个分区。

b>> 如果分区字段中有主键或者唯一索引的列，那么所有的主键列和唯一索引列都必须包含进来。

c>> 分区表无法使用外键约束。

25. MySQL如何判断缓存命中

缓存放在一个引用表中，通过一个哈希值引用，这个哈希值包含：查询本身、当前要查询的数据库、客户端协议的版本等影响返回结果的一些信息。

26. MySQL查询缓存的优缺点

优点：

显著提升查询性能

缺点：

a>> 读查询在开始之前必须先检查是否命中缓存。

b>> 如果这个读查询可以被缓存，那么当完成执行后，MySQL若发现查询缓存中没有这个查询，会将其结果存入查询缓存，会带来额外消耗。

c>> 对写操作有影响，当向某个表写入数据的时候，MySQL必须将对应表的所有缓存设置失效。如果查询缓存非常大或则碎片很多，则可能带来消耗。

27. InnoDB查询缓存

对于InnoDB用户来说，事务的一些特性会限制查询缓存的使用。当一个语句在事务中修改了某个表，MySQL会将这个表的对应查询缓存都设置失效，而事实上，InnoDB的多版本特性会暂时将这个修改对其他事务屏蔽。在这个事务提交之前，这个表的相关查询是无法被缓存的，所以所有的在这个表上面的查询~内部或者外部的事务~都只能在改事务提交后才能被缓存。因此，长时间运行的事务，会大大降低查询缓存的命中率。

其次大内存的使用缓存可能会导致缓存失效的问题。

MySQL4.0版本中，在事务中查询缓存是被禁用的。从4.1和更新的InnoDB版本开始，InnoDB会控制在一个事务中是否可以使用查询缓存，InnoDB会同时控制对查询缓存的读和写操作。

事务是否可以访问查询缓存取决于当前事务ID，以及对应的数据表上是否有锁。每一个InnoDB表的内存数据字典都保存了一个事务ID号，如果当前事务ID小于该事务ID，则无访问查询缓存。同时，如果表上有任何锁，那么对于这个表的任何查询语句都是无法被缓存的。

当事务提交时，InnoDB持有锁，并使用当前的一个系统事务ID更新当前表的计数器。锁一定程度上说明事务需要对表进行修改操作。InnoDB将每个标的计数器设置成某个事务ID，而这个事务ID就代表了当前存在的且修改了该表的最大的事务ID。

a>> 所有大于该表计数器的事务才可以使用查询缓存。

b>> 该表的是计数器并不直接更新为该表进行加锁的事务ID，而是被更新成一个系统事务ID。所以，该事物自身后续的更新操作也无法读取和修改查询缓存。

查询缓存存储，检索和失效操作都是在MySQL服务层面完成的，InnoDB无法绕开或者延迟这一行为。但是InnoDB可以在事务中显式的告诉MySQL何时应该让某个表的查询缓存都失效。

原则上，在InnoDB的MVCC的架构下，当某些修改不影响其他事务读取一致的数据时，是可以使用查询缓存的，但是会非常复杂，所以做了简化，让所有加锁操作的事务都不使用任何查询缓存，这个限制其实并不是必须的。

28. 如何分析和配置查询缓存

29. InnoDB表空间

InnoDB把数据保存在表空间内，本质上是一个又一个或者多个磁盘文件组成的虚拟文件系统。InnoDB用表空间实现很多功能，并不只是存储表和索引。它还保存了回滚日志（旧版本行）、插入缓存、双写缓冲、以及其他内部数据结构。

30. 双写缓冲（Doublewrite Buffer）

InnoDB用双写缓冲来避免页没写完整所导致的数据损坏。

双写缓冲是表空间一个特殊的保留区域，本质上是一个最近写回的页面的备份拷贝。当InnoDB从缓冲吃花心页面到磁盘是，首先把它们写到双写缓冲，然后再把它们写到起所属的数据区域汇总，这可以保证每个页面的写入都是原子并且持久化的。

同时意味着每个页都要写两遍。但是因为InnoDB写页面到双写缓冲都是有顺序的，并且只调用一次fsync()刷新到磁盘，所以实际上性能影响比较小。但是双写缓冲给了InnoDB一个非常牢固的保证，数据也不会损坏。

31. 优化

1.>>假如有一个1000万行的表，占用几个GB的磁盘空间。其中有一个utf8字符集的VARCHAR(1000)的列，每个字符最多使用3个字节，最坏情况下需要3000字节的空间。如果在order by中用到这个列，并且查询扫描整个表，为了排序就需要超过30GB的临时表空间。

优化：可以使用order by substring(column,length)将该列截断，对前length个字符串进行排序。保证临时表的大小不会超过max_heap_table_size或者tmp_table_szie，超过以后MySQL会将内存临时抱转化为MyISAM磁盘临时表，开销极大。

2.>>例如需要存储大量的URL，并需要根据URL进行搜索查找，如果用B-Tree来存储URL，存储的内容会比较大，查询的内容可能如下：

select id from tb_url where url='www.mysql.com'

优化：删除URL列上的B-Tree索引，新增一个被索引的url_crc列，使用CRC32做哈希，插入数据的时候同时插入该列，可以使用下面方式查询，效率会很高。

select id from tb_url where url='www.mysql.com' and url_crc=CRC32('www.mysql.com');

3.>>优化索引之延迟关联

如下查询随着偏移量的增加，MySQL需要花费大量的时间来扫描需要丢弃的数据。

select <cols> from profiles x where x.sex='M' order by x.raring limit 100000,10;
select * from products where actor='alex' and title like '%mysql%';

优化：通过使用覆盖索引查询返回需要的主键，再根据主键关联原表获得需要的行，遮掩可以减少MySQL扫描那些需要丢弃的行数。

select <cols> from profiles inner join (SELECT <primary key cols> from profiles where sex='M' order by raring limit 100000,10) as x using(<primary key cols>);
select * from products p join (select id from products where actot='alex' and title like '%mysql%') as x on x.id=p.id

4.>>优化关联查询

a>>确保关联表ON子句中的列上有索引。在创建索引的时候要考虑到关联的顺序，当表A和表B用列c关联的时候，如果优化器的关联顺序是B、A，那么就不需要在B标的对应列上建立索引，只需要在关联顺序的第二个标的相应列上创建索引。

b>>确保任何的Group By和Order by中的表达式只涉及到一个表中的列，这样MySQL才有可能使用索引来优化这个过程。

5.>>假如我们需要从大约10亿条数据中查询一段时间的记录，这个表包含很多年的历史数据，数据是按照时间排序的，如何查询这表？如何才能更高效？

分析：

a.因为数据量巨大，肯定不能每次查询的时候都扫描全表。考虑到索引在空间和维护上的消耗，也不希望使用索引。即使真的使用索引，你会发现数据并不按照想要的方式聚集的，而且会有大量的碎片产生，最终导致一个查询产生成千上万的随机I/O。

b.在数据量超大的时候B-Tree的索引就无法起作用了，除非是覆盖索引查询，否则数据库服务器需要根据索引扫描的结果回表，查询所有符合条件的记录，将产生大量随便的I/O，同时数据库响应变慢。

c.分区可以将其作为索引的最初形态，以代价非常小的方式定位到需要的数据在哪一片区域中。在这片“区域”中，可以做顺序扫描，可以建立索引，也可以将数据都缓存到内存。因为分区无需额外的数据结构记录每个分区有哪些数据~分区不需要精确定位每条数据的位置，也就无需维护额外的数据结构~

方案：

a>>全量扫描数据数据，不要任何索引。根据分区的规则大致定位需要的数据位置，只要能够使用WHERE条件，将需要的数据限制在少数分区中，则效率也是很高的。

b>>索引数据，并分离热点。将热点数据单独放在一个分区中，让这个分区的数据有机会都缓存在内存中，这样的查询可以只访问一个很小的分区表，能够使用索引，也能够有效的使用缓存。

32. MySQL库复制特性

MySQL支持两种复制方式：基于行的复制和基于语句的复制。这两种方式都是通过在主库上记录二进制日志，在备份库重放日志的方式来实现一步的数据复制。

33. 库复制的流程

第一步：在主库上把数据更改记录到二进制日志文件中。

第二步：备库将主库上的日志复制到自己的中继日志中。

第三步：备库读取中继日志中的事件，将其重放到备库数据之上。

34. 两种复制方式的优缺点

基于语句复制模式

优点：

基于语句的复制方式可以支持更灵活的操作，比如schema，修改表结构的等。本质上来说就是在备库上执行SQL语句，这意味着所有在服务器上发生的变更都比较容易理解，且问题可以很好地定位。

缺点：

很多情况下无法进行正确复制。比如：使用当前的时间戳、或者使用CURRENT_USER()函数的语句。存储过程和触发器在使用基于语句的复制模式时也存在问题。

基于行复制模式

优点：

几乎没有基于行的复制模式无法处理的场景。对于所有的SQL构造、触发器、存储过程都能正确执行。但无法做修改备库表，schema这样的操作。

可以减少锁的使用，因为它并不要求这种强串行化是可重复的。

会记录数据的变更，有一个更好地数据变更记录。另外在一些情况下基于行的二进制日志还会记录发生改变之前的数据，因此有可能有利于数据的修复。

最后，在某些情况下，能更好地帮助找到并解决数据不一致的情况。

缺点：

当复制出现问题时，可能很难找到问题所在，因为行复制不知道SQL语句，像一个黑盒子。

在某些情况下，比如：如果是使用基于语句的复制模式，在备库更新一个不存在的记录时不会报错，但是季宇航的复制模式下则会报错并停止复制。

35. 复制为什么无法扩展写操作

即不能像分发读操作那样把写操作等同地分发到更多的服务器上，换句话说，复制只能扩展读操作，无法扩展写操作。

对数据进行分区是唯一可以扩展写入的方法。

36. 如何生成全局唯一ID？

a>> 使用auto_increment_increment和auto_increment_offset。比如：有两台服务器，配置自增幅度分别为1和2，则，一台服务器总是包含偶数一台则总是包含奇数。

b>> 全局节点中创建表。在一个全局数据库节点中创建一个包含AUTO_INCREMENT列的表，应用可以通过这个表生成唯一数字。

c>> 使用memcached。在memcached的APi中有一个incr()函数，也可以使用redis。memcached方法执行速度快，但是不具备持久性。每次重启memcached拂去都需要重新初始化缓存里的值。

d>> 批量分配数字。应用可以从一个全局节点中请求一批数字，使用完后再重新申请。