auto commit

Author: CyC2018

.gitignore

@@ -1,2 +0,0 @@
-*.txt
-.idea/

notes/MySQL.md

@@ -21,7 +21,7 @@
     * [水平切分](#水平切分)
     * [垂直切分](#垂直切分)
     * [Sharding 策略](#sharding-策略)
-    * [Sharding 存在的问题](#sharding-存在的问题)
+    * [Sharding 存在的问题及解决方案](#sharding-存在的问题及解决方案)
 * [六、复制](#六复制)
     * [主从复制](#主从复制)
     * [读写分离](#读写分离)
@@ -197,9 +197,6 @@ InnoDB 的 B+Tree 索引分为主索引和辅助索引。
 
 <div align="center"> <img src="../pics//7ab8ca28-2a41-4adf-9502-cc0a21e63b51.jpg"/> </div><br>
 
-
-
-
 ### 2. 哈希索引
 
 InnoDB 引擎有一个特殊的功能叫“自适应哈希索引”，当某个索引值被使用的非常频繁时，会在 B+Tree 索引之上再创建一个哈希索引，这样就让 B+Tree 索引具有哈希索引的一些优点，比如快速的哈希查找。
@@ -283,11 +280,11 @@ customer_id_selectivity: 0.0373
 
 索引包含所有需要查询的字段的值。
 
-具有以下优点优点：
+具有以下优点：
 
 - 因为索引条目通常远小于数据行的大小，所以若只读取索引，能大大减少数据访问量。
 - 一些存储引擎（例如 MyISAM）在内存中只缓存索引，而数据依赖于操作系统来缓存。因此，只访问索引可以不使用系统调用（通常比较费时）。
-- 对于 InnoDB 引擎，若二级索引能够覆盖查询，则无需访问聚簇索引。
+- 对于 InnoDB 引擎，若辅助索引能够覆盖查询，则无需访问主索引。
 
 # 四、查询性能优化
 
@@ -346,10 +343,10 @@ do {
 将一个大连接查询（JOIN）分解成对每一个表进行一次单表查询，然后将结果在应用程序中进行关联，这样做的好处有：
 
 - 让缓存更高效。对于连接查询，如果其中一个表发生变化，那么整个查询缓存就无法使用。而分解后的多个查询，即使其中一个表发生变化，对其它表的查询缓存依然可以使用。
+- 分解成多个单表查询，这些单表查询的缓存结果更可能被其它查询使用到，从而减少冗余记录的查询。
 - 减少锁竞争；
 - 在应用层进行连接，可以更容易对数据库进行拆分，从而更容易做到高性能和可扩展。
 - 查询本身效率也可能会有所提升。例如下面的例子中，使用 IN() 代替连接查询，可以让 MySQL 按照 ID 顺序进行查询，这可能比随机的连接要更高效。
-- 分解成多个单表查询，这些单表查询的缓存结果更可能被其它查询使用到，从而减少冗余记录的查询。
 
 ```sql
 SELECT * FROM tab
@@ -370,33 +367,33 @@ SELECT * FROM post WHERE post.id IN (123,456,567,9098,8904);
 
 <div align="center"> <img src="../pics//63c2909f-0c5f-496f-9fe5-ee9176b31aba.jpg"/> </div><br>
 
-水平切分就是就是常见的 Sharding，它是将同一个表中的记录拆分到多个结构相同的表中。
+水平切分又称为 Sharding，它是将同一个表中的记录拆分到多个结构相同的表中。
 
 当一个表的数据不断增多时，Sharding 是必然的选择，它可以将数据分布到集群的不同节点上，从而缓存单个数据库的压力。
 
 ## 垂直切分
 
 <div align="center"> <img src="../pics//e130e5b8-b19a-4f1e-b860-223040525cf6.jpg"/> </div><br>
 
-垂直切分是将一张表按列切分成多个表，通常是按照列的关系密集程度进行切分。也可以利用垂直切分将经常被使用的列和不经常被使用的列切分到不同的表中。
+垂直切分是将一张表按列切分成多个表，通常是按照列的关系密集程度进行切分，也可以利用垂直切分将经常被使用的列和不经常被使用的列切分到不同的表中。
 
-也可以在数据库的层面使用垂直切分，它按数据库中表的密集程度部署到不同的库中，例如将原来的电商数据库垂直切分成商品数据库 payDB、用户数据库 userBD 等。
+在数据库的层面使用垂直切分将按数据库中表的密集程度部署到不同的库中，例如将原来的电商数据库垂直切分成商品数据库 payDB、用户数据库 userBD 等。
 
 ## Sharding 策略
 
 - 哈希取模：hash(key) % NUM_DB
 - 范围：可以是 ID 范围也可以是时间范围
 - 映射表：使用单独的一个数据库来存储映射关系
 
-## Sharding 存在的问题
+## Sharding 存在的问题及解决方案
 
 ### 1. 事务问题
 
-使用分布式事务，比如 XA 接口。
+使用分布式事务来解决，比如 XA 接口。
 
 ### 2. JOIN
 
-将原来的 JOIN 查询分解成多个单表查询，然后在用户程序中进行 JOIN。
+可以将原来的 JOIN 查询分解成多个单表查询，然后在用户程序中进行 JOIN。
 
 ### 3. ID 唯一性
 
@@ -416,21 +413,21 @@ SELECT * FROM post WHERE post.id IN (123,456,567,9098,8904);
 主要涉及三个线程：binlog 线程、I/O 线程和 SQL 线程。
 
 -  **binlog 线程** ：负责将主服务器上的数据更改写入二进制文件（binlog）中。
--  **I/O 线程** ：负责从主服务器上读取二进制日志文件，并写入中继日志中。
+-  **I/O 线程** ：负责从主服务器上读取二进制日志文件，并写入从服务器的中继日志中。
 -  **SQL 线程** ：负责读取中继日志并重放其中的 SQL 语句。
 
 <div align="center"> <img src="../pics//master-slave.png"/> </div><br>
 
 ## 读写分离
 
-主服务器用来处理写操作，而从服务器用来处理读操作。
+主服务器用来处理写操作以及实时性要求比较高的读操作，而从服务器用来处理读操作。
 
 读写分离常用代理方式来实现，代理服务器接收应用层传来的读写请求，然后决定转发到哪个服务器。
 
 MySQL 读写分离能提高性能的原因在于：
 
 - 主从服务器负责各自的读和写，极大程度缓解了锁的争用；
-- 从服务器可以配置 MyISAM 引擎，提升查询技能以及节约系统开销；
+- 从服务器可以配置 MyISAM 引擎，提升查询性能以及节约系统开销；
 - 增加冗余，提高可用性。
 
 <div align="center"> <img src="../pics//master-slave-proxy.png"/> </div><br>