添加more标签

java/其他/java文本，网络等资源自动回收.md

@@ -2,7 +2,7 @@
 id: '2019-03-25-20-52'
 date: '2019/03/25 20:52'
 title: '更优雅的关闭java文本、网络等资源'
-tags: ['java', 'InputStream', 'OutputStream', 'socket','try-with-resource']
+tags: ['java', 'InputStream', 'OutputStream', 'socket', 'try-with-resource']
 categories:
   - 'java'
   - 'java基础'
@@ -34,6 +34,8 @@ public static void main(String[] args) {
 }
 ```
 
+<!-- more -->
+
 在 finally 的关闭代码中，还要再来一个 try/catch，看着是不是很难受，很不优雅，很想干掉这个 finally！
 
 &emsp;&emsp;自从 java7 以来这个问题已经有比较好的解决办法了，那就是**try-with-resource**,可能是 jdk 开发人员也觉得之前的关闭资源写法太反人类，所以做了这样的一个语法糖。注意这并不是什么新特性，只是一个语法糖，简化代码的。如果你反编译代码后会发现还是 try/catch/finally 的传统写法。

数据库/分库分表/sharding-jdbc分库分表.md

@@ -24,6 +24,8 @@ categories:
 
   由此产生了数据分片的概念。按照某个分片维度将存放在单一数据库中的数据分散地存放至多个数据库或表中以提升性能。数据分片的拆分方式分为：垂直分片和水平分片两种。
 
+<!-- more -->
+
 ## 垂直分片
 
 &emsp;&emsp;按照业务逻辑拆分的方式称为垂直分片，又称为纵向拆分。核心理念就是专库专用。将一个大的数据库按照业务逻辑分类，拆分为多个小的数据库，每个业务逻辑使用各自的数据库，从而将压力分散到不同的数据库中。垂直分片往往需要对架构和设计进行调整，类似微服务的概念。但是垂直拆分只能属于一个治标不治本的办法，随着业务量进一步加大，超过了单个表能承受的阈值，还是会出现性能问题。然后就需要水平分片来进一步处理了。

数据库/基础/2.mysql全文检索.md

@@ -26,6 +26,8 @@ ngram_token_size=2
 
 该值默认为 2，范围：1~10.
 
+<!-- more -->
+
 # 建立索引
 
 &emsp;&emsp;对检索字段建立全文索引，注意要选择解析引擎-- **WITH PARSER `ngram`**,如果多多个字段检索，需建立这些字段的联合全文索引。比如下面 name 字段索引只能用于对 name 进行检索。如果要对`name，age`进行检索，需要再建立一个`name，age`的联合全文检索。