• 主页
  • 系列总集
  • OpenCV
  • CMake
  • iOS
  • Java
  • 前端
所有文章 关于我

  • 主页
  • 系列总集
  • OpenCV
  • CMake
  • iOS
  • Java
  • 前端

MySQL查看数据库操作记录

2016-07-28

开启操作记录日志

首先进入mysql输入指令

1
show variables like 'gen%';

可以看到输出

1
2
3
4
5
6
+------------------+-------------------------------------+
| Variable_name | Value |
+------------------+-------------------------------------+
| general_log | OFF |
| general_log_file | /usr/local/mysql/data/localhost.log |
+------------------+-------------------------------------+

可以看到general_log是开启还是环比状态,以及这个帐号的general_log文件在哪,设置开启

1
2
set global general_log=ON;
commit;//如果关闭了自动提交,记得commit一次结束事务

然后就可以去general_log_file的路径查看操作记录了

采用数据库内部查看

出了可以用日志文件的形式查看数据库操作记录之外,也可以把日志作为一个表单,在数据库内部查看

1
2
show variables like '%log_output%';

可以看到输出,然后将其改为表单

1
2
3
4
5
6
7
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_output | FILE |
+---------------+-------+

set global log_output='TABLE';

之后就可以通过以下两句话查看数据库操作记录

1
2
3
select * from mysql.general_log; <=====查看操作记录

truncate table mysql.general_log; <=====清空操作记录表单
  • Server
  • DataBase
  • MySQL
  • Tips

展开全文 >>

MySQL如何重新初始化数据库

2016-07-28

MySQL如何重新初始化

MySQL重新初始化需要以下步骤

干掉日志目录

删除 undolog 和 redolog 里的所有内容,包括隐藏内容

1
2
3

rm -rf /usr/local/mysql/undolog/* /usr/local/mysql/redolog/*

干掉数据目录

干掉Data里的所有内容,不然会提示Data已存在不能重新初始化

1
2
rm -rf /usr/local/mysql/data/*

重新设置错误日志

把error.log在配置文件里放在一个不在以上三个目录的地址,例如

1
log_error = /usr/local/mysql/error.log

重新执行初始化函数

重新执行初始化函数之后,和第一次初始化不同,看不到任何提示信息,所以更别提5.7的初始密码

哪里查看初始化密码

去错误日志 error.log 中可以看到重新初始化生成的初始密码,第二次初始化不会把新的密码写入 /root/.mysql_secret

  • Server
  • DataBase
  • MySQL
  • Tips

展开全文 >>

给SLF4J的日志添加TRACE_ID

2016-07-27

为什么要添加ID

在文章通过日志检查事务是否开启中我们提到了可以通过日志查看日志有没有开启,有个问题是不清楚哪一行日志到底是哪个事务的,在高并发的时候会产生找不到对应日志的问题

slf4j的小工具

我们可以设置一个字段 Constants.TRACE_LOG_ID = “TRACE_LOG_ID” 然后通过sjf4j的MDC单例放入一个随机字符串

1
2
3
4
5
6
7
8
9
10

import org.slf4j.MDC;
import java.util.UUID;

public class LogUtil {
public static void traceLogId() {
MDC.put(Constants.TRACE_LOG_ID, UUID.randomUUID().toString());
}
}

日志配置文件中设置

可以使用自定义关键字 %X{TRACE_LOG_ID} 就可以追踪到日志的ID了

1
2
3
4
5
6
7
8
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<encoder charset="utf-8"> <!-- encoder 可以指定字符集,对于中文输出有意义 -->
<!-- %.-1level 只显示信息级别的首字母,%-5level 左对齐显示信息级别全称 -->
<!-- 如需自定义关键字,用 %mdc{键名} 表示,程序中用MDC.put("键名","键值")设置,可动态设置 [%logger:%line]-->
<Pattern>[%date{yyyy-MM-dd HH:mm:ss}][%thread][%-5level] %c{40} %line --%mdc{client} [%X{TRACE_LOG_ID}] %msg%n</Pattern>
</encoder>>
</appender>

在需要追踪的方法内调用

在需要追踪的方法里调用,由该方法产生的日志就会被放入一个随机的ID

1
2
3
4
5
6
7
public int methodExample(String updateColumn) throws Exception {

LogUtil.traceLogId();

.....
}

  • Java
  • Log
  • Tips

展开全文 >>

通过日志检查事务是否开启

2016-07-27

如何配置JDBC日志

在检查Spring和SpringMVC配置冲突导致事务无法开启和反射调用事务方法导致事务失效引起的异常中,怎么查原因都查不到,最后在同事的介绍下,帮我配置了下数据库日志,可以看到事务是否真的被开启了

用到的组件

打印日志用的是 SLF4J 和 jdbcdslog 其Maven配置如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
<!--slf4j-->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>${slf4j.version}</version>
</dependency>

<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>${slf4j.version}</version>
<scope>runtime</scope>
</dependency>

<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>${slf4j.version}</version>
<scope>runtime</scope>
</dependency>

<dependency>
<groupId>com.googlecode.usc</groupId>
<artifactId>jdbcdslog</artifactId>
<version>1.0.6.2</version>
</dependency>

Slf4j的配置

配置文件为logback.xml 由于不是太熟悉,我采用的是以下配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
<?xml version="1.0" encoding="UTF-8"?>
<configuration>

<!-- 管控台日志打印,发布生产需注释 -->
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<encoder charset="utf-8"> <!-- encoder 可以指定字符集,对于中文输出有意义 -->
<!-- %.-1level 只显示信息级别的首字母,%-5level 左对齐显示信息级别全称 -->
<!-- 如需自定义关键字,用 %mdc{键名} 表示,程序中用MDC.put("键名","键值")设置,可动态设置 [%logger:%line]-->
<Pattern>[%date{yyyy-MM-dd HH:mm:ss}][%thread][%-5level] %c{40} %line --%mdc{client} [%X{TRACE_LOG_ID}] %msg%n</Pattern>
</encoder>>
</appender>

<!-- 外部jar包 日志级别设置 -->
<logger level="INFO" name="com.ibatis" />
<logger level="INFO" name="org.springframework"/>
<logger level="INFO" name="java.sql"/>
<logger level="INFO" name="org.jdbcdslog"/>


<!-- 输出到控制台和文件,可定义更多的 Appender -->
<root level="DEBUG" >
<appender-ref ref="STDOUT"/>
</root>

</configuration>

事务状态和非事务状态的日志

这样在创建Sql的时候就可以看到事务日志和非事务日志的区别,由于我DAL层使用的是MyBatis,看到的是以下日志

为了方便追踪最好给日志加上ID,参考这里给日志添加TraceID

事务状态

1
2
3
4
[2016-07-28 23:17:20][qtp151784151-26][DEBUG] org.mybatis.spring.SqlSessionUtils 120 -- [] Registering transaction synchronization for SqlSession [org.apache.ibatis.session.defaults.DefaultSqlSession@2ac108c2]
......
[2016-07-28 23:17:20][qtp151784151-26][DEBUG] org.mybatis.spring.SqlSessionUtils 163 -- [] Releasing transactional SqlSession [org.apache.ibatis.session.defaults.DefaultSqlSession@2ac108c2]

非事务状态

1
2
3
4
[2016-07-28 23:20:12][qtp151784151-25][DEBUG] org.mybatis.spring.SqlSessionUtils 140 -- [] SqlSession [org.apache.ibatis.session.defaults.DefaultSqlSession@51bdc159] was not registered for synchronization because synchronization is not active
.......
[2016-07-28 23:20:12][qtp151784151-25][DEBUG] org.mybatis.spring.SqlSessionUtils 168 -- [] Closing non transactional SqlSession [org.apache.ibatis.session.defaults.DefaultSqlSession@51bdc159]

  • Java
  • Spring
  • Transaction
  • Log
  • Tips

展开全文 >>

反射调用事务方法导致事务失效

2016-07-27

反射调用事务方法导致事务失效

本文部分作废,可以使用反射调用事务方法,但是需要Invoke的Object不同,参考新文章

不能使用反射方法去调用加了Transactional注解的方法,不然事务会失效

我为什么会作死以及我怎么作死的

在文章SpringMVC和Spring配置冲突的文章的假设中,我的Web层采用了这样一种作死的方式调用Service层

  1. 因为存在模型转换,我有好多个函数要写,又没有人帮我写,每次复制粘贴好烦
  2. 所有函数有都是一样多参数,仅仅是函数名不同

我就作死的使用同一个反射函数,传入不同的Key,Key=函数名,来调用Service这些函数,类似

1
2
3
4
5
6
7
8
@Autowired
private SomeService someService;

@Override
public void insert(ObjectReqVO objectReqVO) {
String key = "serviceInsertMethod";
ReflectUtil.invokeMethod(objectReqVO,someService,key);
}

然而在Service层的 serviceInsertMethod 是如何实现的呢

1
2
3
4
5
@Override
@Transactional(isolation = Isolation.DEFAULT,propagation = Propagation.REQUIRED,rollbackFor = Exception.class)
public void serviceInsertMethod(ObjectReqBO objectReqBO) {

}

我作死中遇到了什么问题(此处有误)

有对Spring事务有一定了解的人都知道其实现原理是JDK的动态代理,如果某方法被加了注解,那么 ReflectUtil.invokeMethod 中得到一个名为Proxy@XXX的动态代理类,而不是 SomeService 类本身

参考如何从动态代理中取Target中我们可以知道,如果想用反射方法获得Method(例如serviceInsertMethod)和Field必须取出Target(例如SomeService)

Spring为了帮你完成事务给你加了动态代理,你为了使用反射给它拆开了,Spring就不能帮你进行事务管理了啊!!!!!

解决方法(此处有误)

呃。。。没有找到,所以调用有@Transactional的方法,还是老老实实的调用吧

1
2
3
4
public void insert(ObjectReqVO objectReqVO) {
ObjectReqBO objectReqBO = BeanUtil.objectConvert(objectReqVO,ObjectReqBO.class);
someService.serviceInsertMethod(objectReqBO);
}
  • Java
  • Spring
  • Reflect
  • Transaction
  • Error
  • Tips

展开全文 >>

Spring和SpringMVC配置冲突导致事务无法开启

2016-07-27

Spring和SpringMVC配置冲突导致事务无法开启

本文原因已经找到,参考文章[最少依赖启动SSM][plus]
[plus]:http://alanli7991.github.io/2016/11/01/从空Pom文件用最少依赖配置SSM框架/

Spring和SpringMVC并不是同一个东西,虽然都是一个公司出的,但是配置上也会冲突导致事务失效

  1. Spring的配置文件
  2. SpringMVC的配置文件

产生冲突的原因

根据配置文件的讲解,必不可少的是扫描component,这里就牵扯到一个问题SpringMVC和Spring都会进行扫描,那谁先谁后呢?

SpringMVC先于Spring进行扫描

我们假设这样的一种情况

后台分层 所用包名 所用组件 所用注解
Web层 com.company.project.web SpringMVC @Controller
Service层 com.company.project.service Spring @Service
DAL层 com.company.project.dal MyBatis 无

根据文章Spring的四个注解解释,@Controller和@Service没有实质上的区别,假如我们使用 com.company.project 作为基础包名配置Spring和SpringMVC就会导致事务失效

会导致失效的SpringMVC的配置

1
2
3
4
5
6
7
<beans .......>

<!-- 进行component扫描 -->
<context:component-scan base-package="com.company.project.*"/>

.......
</beans>

会导致失效的Spring的配置

1
2
3
4
5
6
7
<beans .....>

<!-- 进行component扫描 -->
<context:component-scan base-package="com.company.project.*"/>

.....
</beans>

推测导致失效的原因

  1. 因为Tomcat等容器扫描web.xml的时候有先后顺序,推测是先扫描Servlet然后再扫描Context(大概,不确定)
  2. 使用以上配置导致Servlet加载Component的时候,把Service层的Service也进行了实例化,并且对其加了一系列动态代理
  3. 由于单例模式的原因,导致Context配置无法自己加载Component而是拿到的Servlet实例化的Component的指针
  4. 由于没有由Context进行实例化,导致Spring对Context内容的动态代理无法加载

以上原因是我猜的,也没有验证,因为我在反射问题里也遇到了一个类似的问题导致事务失效

解决事务失效的方法

通过面向百度和Google编程,得到了采用 配置文件中互相排除多余的注解 来防止事务失效

正确的SpringMVC配置

在Servlet中不扫描Service的注解

1
2
3
4
5
6
7
8
<beans .......>

<context:component-scan base-package="com.company.project.*">
<context:exclude-filter type="annotation" expression="org.springframework.stereotype.Service"/>
</context:component-scan>

.......
</beans>

正确的Spring配置

在Context中不扫描Controller的注解

1
2
3
4
5
6
7
8
<beans .......>

<context:component-scan base-package="com.company.project.*">
<context:exclude-filter type="annotation" expression="org.springframework.stereotype.Controller"/>
</context:component-scan>

.......
</beans>
  • Java
  • Spring
  • Configure
  • Transaction
  • Tips

展开全文 >>

Transaction事务的本质和解析

2016-07-27

事务是什么

第一次接触事务的概念,来自于慕课网的教程Spring中的事务,从该教程中可以得知事务分为

  1. 编程式事务
  2. 配置式事务
  3. 注解式事务

其中编程式事务和配置式事务相对来讲用的比较少,注解式事务比较常见,但是不管是哪一种都保持着事务的本性

一组数据库操作,要么全部成功,要么全部失败

ps:教程中也是以转账进行的举例,Transaction本来的含义就是转移和转账,我感觉这个概念的提出就是为了解决 数据的移动 只不过后来慢慢对 一组动作的原子性 有了明确的定义,才翻译成事务

事务如何进行逻辑控制

玩过游戏的都知道有个必杀技叫S/L大法,事务说白了就是存档/读档,也和Git的概念十分相似。那么我就通俗的讲下如何进行逻辑控制

以S/L大法进行举例

数据库的存档叫Commit,数据库的读档叫做Rollback,一旦通过3种方式中任何一个开启事务,将进行以下逻辑操作

游戏逻辑 数据库逻辑
卧槽前面有个BOSS可能打不过 转账操作,可能不能顺利完成
打之前存一下 数据库进行Commit
开始打BOSS 数据库开启事务,进行转账
BOSS挂了,赶紧存一下,别停电了还要重新打 再次Commit结束事务,数据库更变为新状态
你挂了,胜败乃兵家常事,大侠请从新来过 事务发生异常
卧槽,用了三个道具还没打过,赶紧读档,不然这三个道具浪费了 进行回滚Rollback结束事务,数据库保持旧状态

以Git进行举例

巧合的是Git中也有Commit指令,就是对当前的状态进行快照,如果代码写乱了还可以进行Discard和Rollback操作,只不过

事务的Rollback = Git的Discard

Git的逻辑 数据库的逻辑
这代码好狗屎,我要重构它,但是又怕出问题 有个转账交易,不知道能不能成功
先Commit保存一下 先保存当前数据库状态Commit
重构代码 数据库开启事务,进行转账操作
重构的完毕,竟然没BUG,赶快再次Commit 再次Commit结束事务,数据库更变为新状态
卧槽,这是什么意思,卧槽,为什么我这个值有问题,怎么跑不起来了 事务发生异常
卧槽,算了,别给自己找不自在了,还是用旧代码吧,Discard All 进行回滚Rollback结束事务,数据库保持旧状态

事务的传播性和隔壁级别

事务的传播性和隔离级别理解起来比较晦涩,还牵扯到数据库的脏读/不可重复读/幻读,需要在实际编程中自己理解,这里仅仅提醒下比较容易混淆的概念

传播性中”支持”

事务隔离级别 名次解释
PROPAGATION_REQUIRED 如果存在一个事务,则支持当前事务。如果没有事务则开启
PROPAGATION_SUPPORTS 如果存在一个事务,支持当前事务。如果没有事务,则非事务的执行
PROPAGATION_NOT_SUPPORTED 总是非事务地执行,并挂起任何存在的事务
PROPAGATION_NESTED 如果一个活动的事务存在,则运行在一个嵌套的事务中. 如果没有活动事务,按PROPAGATION_REQUIRED 属性执行

这里好多人都是复制过来复制过去,其中最让人难以理解的是 支持当前事务 这是个什么鬼。。。

Speak In Chinese 应该是说 不会对当前事务产生影响 ,所谓产生影响是指不会像 PROPAGATION_NOT_SUPPORTED 一样把另外一个事务暂停,也不会像 PROPAGATION_NESTED 一样,因为自己事务出错,连累另外一个正在运行对事务一起回滚

脏读/不可重复读/幻读

这三个坑爹的名次是英文直译,比较容易让人晕,这里列个表区别下

脏读和不可重复读

相同点 不同点
读数据的时候,被人改了 脏读是只读一次,不可重复读读了多次

不可重复读和幻读

相同点 不同点
都是读取多次 两次读的内容不一样是不可重复读,两次读的条数不一样(有增删操作)是幻读

流程模拟

1
2
3
4
5
6
7
8
9
10
11
12
13
事务1:更新一条数据
------------->事务2:读取事务1更新的记录(事务2脏读)
事务1:调用commit进行提交

事务1:查询一条记录
-------------->事务2:更新事务1查询的记录
-------------->事务2:调用commit进行提交
事务1:再次查询上次的记录(事务1不可重复读)

事务1:查询表中所有记录
-------------->事务2:插入一条记录
-------------->事务2:调用commit进行提交
事务1:再次查询表中所有记录(事务1幻读)

Spring的事务和数据库的事务的区别

在了解了事务的工作机制,好多人都会产生一个疑问,Spring中也有事务,数据库也有事务,他们的区别和联系是什么?这里首先明确一个概念

事务是一个仅仅存在于数据库的概念,Spring的事务本质也是数据库进行的

如何链接到数据库

在我们想要通过某种方式(比如客户端)连接到数据库时,需要知道以下的属性

  1. IP地址
  2. 端口
  3. 帐号
  4. 密码

既然有了IP地址和端口号,这分明就是IP协议嘛,所以说 无论以何种方式接入数据库,都是基于传输层的TCP/IP协议

正式由于如此,除了通过设定好的IP和端口链接数据库,也可以使用某个Socket,详细参见Sokcet与TCP/IP的关系

Spring如何连接到数据库

在Spring的事务中,必须配置的类是 transactionManager 它有一个属性叫 datasource,而datasource又是一个jdbc的数据源,我们通过配置datasource的URL可以知道

1
jdbc:mysql://127.0.0.1:3306/database

是不是感觉和 http://xxxx 有种似曾相识的感觉,所以说Spring在 连接到数据库之后,使用了应用层的jdbc:mysql:协议 对数据库进行操作

Spring操作数据库

这样以来也就不难发现,所谓Spring的事务——其实就是Spring通过与数据库的链接,使用某种应用层协议操作数据库事务本身

除了Spring可以操作数据库的事务以外,MyBatis,Hibernate,Jdbc等等都有事务的概念,但是它们同Spring一样 仅仅是操作数据库

事务实际逻辑运行的地方,还是数据库本身

Spring事务的坑

我在编程中碰到过两次大坑导致事务失效

  1. SpringMVC和Spring配置冲突导致事务无法开启
  2. 通过反射调用事务方法导致事务失效

在填坑之前,首先看看如何检查事务是否正常开启

  • Java
  • Spring
  • Transaction
  • Tutorial

展开全文 >>

Jetty后台启动

2016-07-24

Jetty后台启动

除了使用以下命令启动外

1
[root@localhost jetty]# java -jar start.jar

还可以通过

1
[root@localhost jetty]# bin/jetty.sh start

进行后台启动,日志会写入日志文件而不是显示在命令行上

  • Servlet
  • Server
  • Tips

展开全文 >>

Jetty的启动后图形验证码X11错误

2016-07-24

Jetty的启动后图形验证码X11错误

在经历的错误的配置后又手动捣鼓起来的服务器后,发现图形验证码不能用,且服务器日志报错

1
2
-(java.lang.InternalError): Can't connect to X11 window server using ':0.0' as the value of the DISPLAY variable.

貌似是一个Linux下的图形服务没有正常启动的缘故,解决办法:

  1. 如果服务器上安装有图形界面,可以通过设置环境变量:DISPALY=127.0.0.1:0.0解决。
  2. 如果没有安装图形界面,可以在Java运行时加上参数:-Djava.awt.headless=true。
  3. 修改服务器配置文件,总之开启-Djava.awt.headless
  • Servlet
  • Server
  • Tips

展开全文 >>

MySQL配置文件详细分析

2016-07-24

MySQL配置文件讲解

为了更加透彻的理解MySQL的配置文件,从同事那里要来了一份他 私人的配置文件总结(前爱奇艺/百度数据库工程师张xx)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
# my.cnf
# 所有对参数的注解都在该参数的上方。未明确列出的参数请使用默认值。
# 该文件只是部分优化的参数模板。具体优化值可以根据自身的业务场景进行优化。
# 版本:MySQL/MariaDB 5.5
# Author: Perry.Zhang

[client]
port = 3306
socket = /tmp/mysql.sock

[mysql]
prompt="\\u@\\h [\\d]>"
#tee=/data/mysql/mysql_3306/data/query.log
no-auto-rehash

[mysqld]
# ---------- BASE CONFIGURE ----------
# 启动MYSQL数据库的用户
user = mysql
# MYSQL守护进程启动时监听的端口
port = 3306
# MYSQL安装路径:源码安装时在CMAKE_INSTALL_PREFIX注明
basedir =
# MYSQL数据文件存放路径:存放独立表空间文件、索引文件(MYI)、表结构文件(.frm)会按照模式(Schema)进行区分。
datadir =
# MYSQL插件存放路径。默认为BASEDIR/lib/plugin。
# 注:如果启动服务时出现找不到ha_xxxx.so的文件时,可能的原因是系统本身自带的MYSQL服务没有卸载干净。导致服务无法正确加载插件。
# 处理的方法是手动指定插件存放路径。
plugin_dir =
# MYSQL sock文件存放路径:该目录可以改动,但必需可以让mysql有写权限
socket = /tmp/mysql.sock
# MYSQL pid文件存放路径。
pid-file = mysql.pid
# 关闭计划任务--事件调度器(默认关闭,可以不加该条)
# event_scheduler = 0
# 初始化客户端连接:对super用户无效。
# 注:HUPU场景里设置可以保证客户端字符集未设置是utf8时的客户端连接保持Latin1字符集
# init_connect = 'set names latin1; SET CHARACTER SET latin1;'
# MYSQL SERVER字符集
character-set-server = utf8
# 事务隔离级别:MYSQL默认为REPEATABLE-READ。事务隔离级别从低到高依次为:READ UNCOMMITTED、READ COMMITTED、REPEATABLE-READ、SERIALIZABLE。
transaction-isolation = REPEATABLE-READ
# 表名不区分大小写:0,否;1,是
lower_case_table_names = 1
# 不进行DNS域名解析:0,否;1,是。
# 注: 1)不管使用IP还是HOST,MYSQL都会做域名反向解析。因此该参数最好开启,否则可能出现反查解析过慢引起的远程连接MYSQL变慢。
# 2)开启该参数后,授权表中请使用IP替换域名做权限设置。
skip-name-resolve
# MYSQL实例在大量发时,而MYSQL处理不过来,就会产生最大连接错误,当达到设定值后会锁死实例,新的连接将无法进来,而老的连接正常。
max_connect_errors = 100000
# 是否关闭授权表。一般只用在忘记服务器权限需要重置时,生产环境中不能开启。
# skip-grant-tables

# ---------- GLOBAL CACHES、BUFFER AND LIMITS ----------
# 为顺序扫描(顺序读)线程分配的缓冲池大小。必须为4KB的倍数。如果设置不为4KB的倍数时会向下取整。通常顺序读多的场景需要加大该值。最大2GB。
# 还有如下场景会用到该值:
# 1.使用ORDER BY做排序时,需要在临时文件(不是临时表)中缓存索引
# 2.大块INSERT插入分区
# 3.嵌套查询缓存结果集
# 注:该值针对每个线程分配,设置过大会影响并发性能。
# 优化建议:顺序读较多的场景可以适当增大该值。
read_buffer_size = 2M
# 为随机扫描(随机读)线程分配的缓冲池大小。查询中有大量使用ORDER BY子句做排序操作的,可以增大该值。最大2GB。
# 注:该值针对每个线程分配,设置过大会影响并发性能。
# 优化建议:最好只在较大结果集的ORDER BY子句的session里增大该值。
read_rnd_buffer_size = 8M
# 为排序操作的线程分配的缓冲池大小。全引擎通用。无法被查询优化器和索引优化的查询会使用该缓冲区。
# SHOW GLOBAL STATUS LIKE 'SORT_MERGE_PASSES' 的值过大时,可以考虑调高该值。
# 注:该值要符合业务场景需要,不要设定太大(因其即使未使用也会全部分配)且针对每个线程分配。最大可分配大小为4G-1(32 bit)。64 bit系统可以分配更大(除了64位windows)。
# 优化建议:LINUX系统下该值的阈值在256K-2M之间。官方文档称超过2M会出现明显的性能下降。建议GLOBAL值设为4M(每4G内存)。增大该参数以提高ORDER BY 或GROUP BY场景可以动态修改SESSION值。
sort_buffer_size = 4M
# 为普通索引扫描、范围索引扫描、没有使用索引而导致全表扫描的JOIN分配的缓冲池大小。
# 注:该值要符合业务场景需要,不要设定太大(因其即使未使用也会全部分配)且针对每个线程分配。最大可分配大小为4G-1(32 bit)。64 bit系统可以分配更大(除了64位windows)。
# 优化建议:GLOBAL设小,SESSION值可以调大(在优化时).因为分配超过需要的过大内存会导致严重的性能下降。
join_buffer_size = 8M
# MYSQL允许并发会话数上限。默认151.阈值1-100000。
max_connections = 4096
# 最大打开文件数(mysqld文件描述符限制)。最大值为系统允许最大值,linux使用ulimit -n命令查看。
# 优化建议:应用出现Too many open files错误时需要增大该参数.
open_files_limit = 65535
# 表打开缓存。该参数控制开表缓存的大小,用于加快表访问速度。
# 优化建议:SHOW GLOBAL STATUS LIKE 'OPENED_TABLE'的值过大且不使用FLUSH TABLES手工关闭打开表时,可以增大该参数。
# 注:MYISAM引擎主要需要优化的是该参数与KEY_BUFFER_SIZE
table_open_cache = 1024


# ---------- TEMPORARY TABLE ----------
# 创建在内存中的临时表大小(内部heap表大小)。查询语句中有大量GROUP BY子句或机器有较大内存时,可以考虑加大该值。
# 注:其阈值为与max_heap_table_size两个值中最小的一个。
# 当内部heap表超过tmp_table_size设定值后,MYSQL会将基于内存heap表转换为基于磁盘的MYISAM表。
# 优化建议:1)SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables'/'Created_tmp_tables'
# Created_tmp_disk_tables:执行SQL语句时在磁盘中创建的临时表数量;
# Created_tmp_tables:执行SQL语句时创建的临时表的总数,该值比Created_tmp_disk_tables大。
# 二者差值为创建在内存中的临时表。
# 2)如果Created_tmp_disk_tables过大或Created_tmp_tables-Created_tmp_disk_tables差值过小,
# 表明tmp_table_size或max_heap_table_size的值过小。可以考虑增大该值。
tmp_table_size = 256M
# 定义用户可以创建的内存表(memory table、heap引擎)最大值,用来计算内存表的最大行值。
# 注:MYSQL的内存表为堆表。
max_heap_table_size = 256M

# ---------- QUERY CACHE ----------
# 是否开启QC。
# 注:SHOW GLOBAL VARIABLES LIKE 'HAVE_QUERY_CACHE'; //查看MYSQL是否支持QC。
# SHOW GLOBAL STATUS LIKE '%QC%'; //查看与QC相关的
# 1)Qcache_hits:QC命中查询数
# 2)Qcache_inserts:QC写入查询数
# 3)Qcache_not_cached:QC未缓存查询数(QC关闭时也会记录)
# 优化建议:
# 1)大并发场景(类似双十一)可以关闭。但是要求应用中的SQL语句必须通过索引查询且分配给MYSQL的内存也要大,否则会造成严重的性能问题。
# 2)场景中有表频繁更新可以考虑让应用在针对频繁更新的表的查询时增加SQL_NO_CACHE标签。
# 3)误区:加空格、TAB、注释等会被MYSQL当成一个新查询存入QC。
# 纠正:前后空格、TAB等将被过滤,都算作一个查询。
# 取值范围:
# 0:关闭。不分配QC所需的内存空间。
# 1:缓存所有查询。加SQL_NO_CACHE标签的除外。
# 2:只有带SQL_CACHE标签的查询才会使用QC。
query_cache_type = 0
# QC大小。最小为40K。小于40K会触发WARNING.
# 注:SHOW GLOBAL VARIABLES LIKE 'Qcache_lowmem_prunes'值可以帮助调整query_cache_size的大小。
# Qcache_lowmem_prunes:由于query_cache_size太小而导致查询从QC中删除的数量。
# 优化建议:当发现Qcache_lowmem_prunes过大时,可以考虑调整query_cache_size的大小。
query_cache_size = 128M
# 单个查询能够使用的QC大小,默认1M
query_cache_limit = 2M
# 分配给QC的最小块大小。默认值4096
query_cache_min_res_unit = 512

# ---------- THREAD CACHE ----------
# 线程缓存大小。控制被缓存的线程数。
# 注:SHOW GLOBAL STATUS LIKE 'Threads%'; //查看与线程相关的状态值
# 1)Threads_cached:线程缓存中的线程数。
# 2)Threads_connected:当前打开的连接数。
# 3)Threads_created:创建用来处理连接的线程数(没有使用线程缓存中的线程时,该状态会增加)。
# 优化建议:当Threads_created过大时可以考虑增大thread_cache_size的值。
thread_cache_size = 1024
# 每个线程创建时分配的堆栈大小。默认192K(32 bits),256K(64 bits)。
# 注:线程使用的堆栈设置太小,会影响线程可处理的SQL语句的复杂程度、存储过程的递归深度及其他消耗内存的行为。
# 优化建议:在大多数场景中,使用默认值即可。在需要大量使用存储过程且循环较深的场景中,可以适当加大该值,但是不推荐。
thread_stack = 256K
# MYSQL线程处理模型。共no-threads、one-thread-per-connection(设为该值时将使用线程缓存)、dynamically-loaded
# dynamically-loaded:开启线程池时使用。(注:MariaDB中该值为pool-of-threads)
thread_handling = one-thread-per-connection

# ---------- THREAD POOL ----------
# 1. 线程池中worker线程处理单位为1个statement。而不是one-thread-per-connection一个线程只处理一个连接。
# 2. 线程池被划分为多个组(N个GROUP)。连接发送的SQL根据线程ID不同分配到不同的GROUP中。因此,一个连接发送的多个SQL是由同一个WORKER线程进行处理的。(SQL对应的线程组可以通过 线程ID % thread_pool_size 取模的算法得出)
# 3. 每个group都有2个任务队列,即优先队列和普通队列如果一个sql所在的事务已经开启,则将任务放到优先队列中,否则放到普通队列中,worker线程优先从优先队列中取任务执行,当优先队列为空则从普通队列取任务执行,这个可以保证已经开启的事务优先得到执行,从而尽早释放其占用的资源(主要是锁),可以有效减小响应时间,别且避免调度上的死锁(A和B被分到不同的group中,A事务已经开启,并且获得了锁,可能无法立即得到调度执行,B事务依赖A事务释放锁资源,但是先于A得到调度)
# 注:下面的参数主要使用在MariaDB中。
# 线程池中线程组的大小。默认值16。
# thread_pool_size = 16
# 该值的作用是防止线程池中的线程出现假死,设定值为timer线程检测间隔时长。
# 若超过该值线程无响应,则线程池会创建新的线程。
# MYSQL5.5:单位10毫秒,默认值6,60ms。阈值4-600,40ms-6s(奇葩的设置).
# MariaDB:单位毫秒,默认值500.
# thread_pool_stall_limit = 500
# 线程池中最大线程数量。默认值MDB5.5-10.0为500,10.1后为10000。
# thread_pool_max_threads = 500
# 空闲的线程退出时间间隔。默认值60s。
# thread_pool_idle_timeout = 60
# 控制每个Group里同时可以运行多少个任务。5.5一般在128个任务比较好。如16核的机器该值可以设定为8-10.
# thread_pool_oversubscribe = 8

# ---------- TIMEOUT ----------
# 关闭一个交互连接时等待的秒数。
# 注:该值设置过小会造成一些查询无法返回结果,应用端出现server has gone away的2006错误。
interactive_timeout = 3600
# 关闭空闲连接时等待的秒数。
# 注:该值设置过大会造成并发场景中连接数飙高,或连接线程不释放引起的SLEEP状态线程过多的问题。
wait_timeout = 3600

# ---------- ERROR LOG & SLOW LOG ----------
# 指定GENERAL QUERY LOG和SLOW LOG的存储形式。值为:TABLE(日志记录在表里)、FILE、NONE。默认为FILE。
# 注:如果设置为NONE那该参数要放在所有日志参数的最前面。
log-output = file
# SLOW LOG开关及存放路径。
slow_query_log = 1
slow_query_log_file = $YOUR_SLOWLOG_PATH/mysql-slow.log
# 设置超过n秒的查询记录到SLOW LOG中。默认10S。
long_query_time = 1
# 是否将管理语句记录到慢查询中,如ALTER TABLE, ANALYZE TABLE, CHECK TABLE, CREATE INDEX, DROP INDEX,OPTIMIZE TABLE, REPAIR TABLE。默认0,关闭。
# 优化建议:不建议开启该参数。会加大磁盘IO。
# log-slow-admin-statements = 0
# 是否允许慢日志记录slave sql线程执行的sql语句。
# log-slow-slave-statements = 1

# 错误日志存放路径
log-error = $YOUR_ERRORLOG_PATHmysql-error-log.err
# 是否将警告信息记录到错误日志。默认设定为1,表示启用;设置为0为禁用;而其值为大于1时表示新发起连接时产生的ABORTED CONNECTIONS和ACCESS-DENIED也会被记录到错误日志。
log_warnings = 2

# GENERAL LOG
# general_log = 1
# general_log_file = general.log

# ---------- MYISAM ----------
# MYISAM键缓冲区大小。可以加快索引读及多重写入的速度。默认为8M。
# 优化建议:可以根据自身物理内存的大小增加该值。但是不要超过物理内存的50%。理论上物理内存的25%都可以用做该值。
key_buffer_size = 128M
# MYISAM引擎批量插入暂存使用内存。默认为8M。
# 注:会加速形如 INSERT ... SELECT,INSERT ... VALUES (...), (...) and LOAD DATA INFILE语句。
bulk_insert_buffer_size = 32M
# MYISAM引擎排序缓冲大小。
# 注:实际是指REPAIR TABLE、或使用CREATE INDEX/ALTER TABLE创建索引时,重新排序索引所需的缓冲区大小。
myisam_sort_buffer_size = 128M
# MYISAM重建索引使用的临时文件的最大大小。
# 注: 1)REPAIR TABLE, ALTER TABLE, LOAD DATA INFILE会重建索引。
# 2)该值设置过小时,重建索引操作会使用KEY BUFFER,从而引起读性能下降。
myisam_max_sort_file_size = 10G
# MYSQL修复线程数
myisam_repair_threads = 1
# 允许在实行CREATE TABLE语句时使用DELAY_KEY_WRITE选项,如果表已存在可以使用ALTER TABLE语句修改。控制MYISAM索引延迟写入磁盘。共3个值:OFF/ON/ALL,默认值ON。
# 注:开启后,修改数据时数据文件更改会先刷入磁盘,索引文件更改会暂存于内存中(KEY BUFFER),在表关闭时刷入磁盘。
# 优化建议:1)MYISAM频繁更新的大表(千万级别)可以开启该功能。有效提高写性能。
# 2)由于该参数会导致服务器突然断电后重启服务时表损坏,因此需要配合myisam_recover_options参数使用,防止出现数据不一致的情况。
delay_key_write = ON
# MYISAM引擎恢复模式。默认值OFF。
# 1)OFF 关闭。
# 2)DEFAULT 不使用BACKUP/FORCE/QUICK进行恢复。
# 3)BACKUP 若在恢复过程中数据文件发生改变,则将table_name.MYD文件备份为table_name-datetime.BAK。
# 4)FORCE 强制恢复。可能丢失数据。
# 5)QUICK 如果没有删除块时,不检查表中的行。只有在参数external locking(系统锁,默认4.0版本之后为关闭)关闭的时候起作用。
myisam_recover_options = DEFAULT

# ---------- INNODB ----------
# INNODB缓冲池大小。
# 注:理论值为机器物理内存的75%-85%。该值过小会导致频繁的磁盘IO。
innodb_buffer_pool_size =
# 设置innodb buffer pool被分割成的个数,用来提高并发性,减少锁争用,默认值为1。5.6后改为8.
# 注:设置该参数时innodb_buffer_pool_size必须要大于1G。
innodb_buffer_pool_instances = 1
# INNODB共享表空间文件。
# 注: 1)可以指定多个共享表空间文件,使用;分隔。但是只有最后一个文件支持autoextend或max选项。
# 2)不指定路径时默认存放在MYSQL的data文件夹下。
innodb_data_file_path = $YOUR_INNODBDATAFILE_PATH/ibdata1:1G:autoextend
# 控制innodb调用系统fsync刷盘策略。默认值为1.
# 灾难情况:1)MYSQL CRASH
# 2)OS CRASH
# 取值范围:
# 0:每秒Log Thread将log buffer中的数据写入log file并通知文件系统同步文件。
# 注:由于事务提交时不进行刷盘所以会丢失1S内提交的事务。
# 1:每个事务提交时Log Thread将log buffer中的数据写入log file并通知文件系统同步文件。
# 注:数据安全性最高。灾难情况不会丢失已提交的数据。
# 2:每个事务提交时Log Thread将log buffer中的数据写入log file但不刷盘,每秒通知文件系统同步文件。
# 注:a)不过由于CPU的进程调度问题,不能保证100%是每秒执行一次flush disk。
# b)MYSQL CRASH不会丢失事务。但是由于文件系统有cache所以实际是写入cache中,OS CRASH时会丢失没有刷盘的事务。
# 优化建议:1)对数据安全性要求不高的场景不要使用1.设置为2会提高写入性能。
# 2)对数据安全性要求高的场景建议使用1.但是要配合sync_binlog = 1来提高安全性。
innodb_flush_log_at_trx_commit = 2
# INNODB日志缓冲大小。默认值为8M。
# 注:该参数实际是指日志刷盘前在日志缓冲区中存储脏页大小。
# 优化建议:理论最大值4G-1但是建议不要超过64M。因为该缓冲区中的内容会由innodb_flush_log_at_trx_commit参数控制刷新到磁盘上,该值过大会导致灾难情况时的数据丢失。
innodb_log_buffer_size = 32M
# FLUSH LOG BUFFER中脏页的百分比。
# 优化建议:推荐值区间为75%-95%。如果写入数据为冷数据的场景可以将该值调低,为热数据是可以将该值调高。
innodb_max_dirty_pages_pct = 75
# INNODB LOG FILE(ib_logfileN)大小。
# 注:LOG FILE中存放的是REDO LOG信息。
# 优化建议:1)取值范围可以在1M-1/N BUFFER_POOL_SIZE之间(N为每个日志组中的日志数)推荐256M以上,但不要超过1G,过大的LOG FILE会使恢复速度变慢。
# 2)过小的LOG FILE会使CHECKPOINT比较频繁,导致刷新脏页到磁盘的次数增加,在刷新时整个系统变慢。
# 3)合理值计算方法:
# a)通过SHOW ENGINE INNODB STATUS\G命令获得Log sequence number和Last checkpoint at值,求差记为RESULTS。
# b)由公式(innodb_log_file_size * innodb_log_files_in_group(default 2)) * 0.75 = RESULTS,求得innodb_log_file_size。
innodb_log_file_size = 512M
# INNODB日志组。默认值为2.
innodb_log_files_in_group = 3
# INNODB日志存放路径。
innodb_log_group_home_dir = $YOUR_LOGFILE_PATH
# 控制Innodb checkpoint时的IO能力,默认值是200。
# 优化建议:一般可以按一块SAS 15K转的磁盘按200计算,6块SAS做Raid10则可以设为600。如果普通的SATA一块盘只能按100算。ssd可以为2000或更高。
innodb_io_capacity = 2000
# 控制INNODB DATAFILE 及 REDO LOG的打开、刷新模式。
# 取值范围:
# 1)fsync(默认):调用系统级fsync()刷写数据文件与redo log的innodb log buffer。
# 2)O_DSYNC:innodb使用O_SYNC方式打开和刷写redo log,使用fsync()刷写数据文件。在UNIX系统中问题较多,不推荐使用。
# 3)O_DIRECT:innodb使用O_DIRECT打开数据文件,使用fsync()刷写数据文件跟redo log。
# 注:
# 1)fsync(int fd)函数:该函数作用是执行flush操作时,将与fd文件描述符所指文件有关的buffer刷写到磁盘中。并且刷写完元数据的信息(比如修改日期、创建日期等)后执行完毕。
# 2)见图。
innodb_flush_method = O_DIRECT
# 开启独立表空间。5.6后默认开启。
innodb_file_per_table = 1
# 事务超时会导致InnoDB中止并回滚整个事务.默认关闭。
innodb_rollback_on_timeout = 1
# 用于灾难恢复的选项。默认值为0.
# 注:没有特殊情况时一定设置为0.大于0的值会导致无法写入。
innodb_force_recovery = 0

# ---------- REPLICATION & BINLOG ----------
# 服务器id。最好使用某种固定格式。复制标识。
server-id =
# binlog格式 [STATEMENT(基于语句)|ROW(基于行)|MIXED(混合模式)]
# 注:基于行的复制有一些缺点
binlog_format = row
# binlog位置及binlog index位置.
log-bin = mysql-bin
log_bin_index = mysql-bin.index
# 指定binlog文件最大容量。超过设定值后MYSQL会自动切换binlog。
max_binlog_size = 1G
# binlog缓存大小。
# 注:该值针对每个线程分配,设置过大会影响并发性能。
binlog_cache_size = 4M
# binlog 能够使用的最大cache内存大小。
max_binlog_cache_size = 2G
# 控制binlog同步到磁盘的策略。默认值为0.
# 取值范围:
# 0:当事务提交之后,MySQL不调用fdatasync()函数刷新binlog_cache中的信息到磁盘,而让文件系统决定什么时候来做同步,或者在binlog_cache满了后才同步到磁盘。
# N:每向binlog中写入N次后,才调用fdatasync()函数。
# 注:如果启用了autocommit,那么每条语句都算作一次写入binlog。未开启时每个事务算作一次写入binlog。
# 优化建议:1)对数据安全性要求不高时建议使用默认值。
# 2)innodb_flush_log_at_trx_commit = 1 且 sync_binlog = 1时写性能最差但安全性最高。
# 3)N > 1时的写性能比N = 0时高。
sync_binlog = 0
# 开启后在binlog中记录annotate event,用来在ROW模式下展示SQL语句。
binlog_annotate_row_events = 1
# 过滤选项
# binlog-do-db = $YOUR_DB_NAME
# binlog-ignore-db = $YOUR_DB_NAME
# binlog-wild-do/ignore-db = $YOUR_DB_NAME
# binlog自动删除时间。
expire_logs_days = 7

# ---------- REPLICATION & RELAYLOG(JUST FOR SLAVE)----------
# 设置MYSQL服务启动时不自动开启复制。
# 注:多数场景不要开启。
# skip_slave_start = 1
# 过滤选项。
# replicate_do_db = $YOUR_DB_NAME
# replicate_ignore_db = $YOUR_DB_NAME
# replicate-wild-do/ignore-db = $YOUR_DB_NAME
# 最大中继日志大小。
# max_relay_log_size = 1G
# relay_log_purge = 1
# relay_log_recovery = 1
# 开启从库上的更新记录到从库自己的binlog中。默认为0或OFF。
# 注:1)M-M架构:建议都开启该参数。防止自动切换时无法记录binlog导致数据丢失。
# 2)M-S1-S2架构:作为中继层的从库S1必须要开启。这样S2才会从S1中得到binlog更新。
# 3)由于MYSQL的binlog会记录执行SQL的源server_id。所以在1这种情况下,两台M都开启也不会形成循环复制。
# log_slave_updates = 1
# 开启后在relay-log中记录annotate event,用来在ROW模式下展示SQL语句。
# 注:只能在开启log_slave_update参数的从库上使用。
replicate_annotate_row_events = 1
# 从库SQL线程跳过的错误号。
# slave-skip-errors = 1032,1053,1062

[mysqldump]
quick
# 导出时指定单表最大文件
max_allowed_packet = 1G

  • Server
  • DataBase
  • MySQL
  • Tips

展开全文 >>

&laquo; Prev1…2526272829…45Next &raquo;
© 2021 Alan Li
Hexo Theme Yilia by Litten
  • 所有文章
  • 关于我

tag:

  • iOS
  • Java
  • Collection
  • Python
  • Shell
  • CMake
  • Memory
  • JavaScript
  • Architecture
  • AnchorPoint
  • Android
  • Web
  • Annotation
  • AFNetworking
  • Window
  • ViewController
  • AutoLayout
  • Dozer
  • CoreAnimation
  • Cycle Retain
  • Block
  • UI
  • IDE
  • FrontEnd
  • CSS
  • Category
  • TableViewCell
  • Security
  • Net
  • JSP
  • Spring
  • C
  • MyBatis
  • Date
  • React
  • GCD
  • UITouch
  • Gesture
  • UIControl
  • Git
  • HTML
  • HTTPS
  • HTTP
  • Servlet
  • Server
  • DataBase
  • MySQL
  • Linux
  • Tutorial
  • Ajax
  • Type
  • JQuery
  • JSON
  • Exception
  • Parameter
  • Reflect
  • Thread
  • Sort
  • KVO
  • MKMapKit
  • Overlay
  • Maven
  • Configure
  • Tips
  • Transaction
  • Swift
  • NavigationBar
  • Nginx
  • Runtime
  • OpenCV
  • Property
  • Playground
  • Protocol
  • Redux
  • ScrollView
  • Session
  • Cookie
  • Shiro
  • Error
  • Singleton
  • RegEx
  • StackView
  • StatusBar
  • Base64
  • Socket
  • TCP
  • IP
  • TextField
  • CALayer
  • UILabel
  • View
  • Animation
  • Xcode
  • Hexo
  • Terminal
  • OC
  • Device
  • Log
  • Image
  • JUnit
  • Oval
  • Archive
  • XSS
  • Compiler
  • Aspect
  • Responder
  • Class
  • FireWall
  • RetainCount
  • Const
  • Frame
  • String
  • Symbols
  • Framework
  • CocoaPods
  • Unity
  • Message
  • Button
  • AuthorizationStatus
  • Struct
  • XCTest
  • NSNotification
  • Contact

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录(注意不是yilia根目录)执行以下命令:
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置:

      jsonContent:
        meta: false
        pages: false
        posts:
          title: true
          date: true
          path: true
          text: false
          raw: false
          content: false
          slug: false
          updated: false
          comments: false
          link: false
          permalink: false
          excerpt: false
          categories: false
          tags: true
    

我写的,大概率是错的。。。。。