WordPress深度加速-OpenLiteSpeed环境下的WordPress数据库优化设置详细教程

对于WordPress来说，需要优化的地方非常多，从前端到后端有非常多的优化手段，比如安装WordPress的优化缓存加速插件，但是有时候数据量一大，最终都是感觉很卡，该做的优化步骤都做了，那如何解决呢？这个时候，我们就可以进行WordPress的深度优化加速了，也就是WordPress数据库优化设置。前端优化加速插件的应用等这里搬主题就不多说，毕竟网上教程很多，搬主题专门介绍一下WordPress的数据库如何优化加速。这里分享优化设置的详细教程。

服务器环境：

OpenLiteSpeed 1.6.18
PHP 7.4
MariaDB 10.5
WordPress 5.6
CyberPanel 2.0.3

一、WordPress数据库的优化方向

因为WordPress的数据库一般是MySQL或者MariaDB（MariaDB是MySQL的一个分支，完全兼容MySQL），而我们要优化数据库的最终目的是让WordPress的页面访问速度更快，而WordPress的架构导致每打开一个页面，均要进行数据库的查询，查询次数越多，则页面访问速度越慢。这里我们的WordPress数据库的优化方向则为减少数据库的查询次数，从而达到WordPress的优化加速作用。

减少数据库的查询次数的方法主要有几个：

1、直接修改WordPress主题模板，尽量减少数据库及PHP调用次数
2、开启数据库查询缓存
3、设置数据库索引缓存

接下来搬主题就针对这三个方向进行相应的优化。

二、开启数据库查询次数及时间显示

在这之前，搬主题先分享一下如何开启数据库查询次数及时间显示。

将如下代码放到自己的WordPress主题模板内的footer.php 里既可。

本页加载数据库查询<?php echo get_num_queries(); ?>次，加载用时：<?php timer_stop(1); ?>秒

一般都加在最底部的</div>前即可。根据自己实际位置需要进行调整。这样保存后就可以直接显示每个页面的数据库查询次数及相应的加载时间显示了。

注意：如果开启了缓存插件，比如搬主题开启了LiteSpeed Cache插件，则只会在第一次加载时显示查询次数，然后就页面就直接被缓存了，再次加载也不会变化，因此如果要调试的话，可以先暂时关闭缓存插件。

三、修改WordPress主题模板

一般我们安装了各类的WordPress主题模板，在模板中会大量的调用相应的数据库字段及PHP调用。我们首先要减少因为主题和其他一些不必要的数据库查询。

打开WordPress 根目录下的 wp-config.php 文件，在后面加入如下的代码，然后保存，刷新自己的缓存。

define('COOKIE_DOMAIN', 'www.banzhuti.com');
//设置地址而不是服务器检查,这将减少服务器查询
define('WP_HOME', 'https://www.banzhuti.com');
define('WP_SITEURL', 'https://www.banzhuti.com');
//优化文章修改历史：Post-Revisioning
define('AUTOSAVE_INTERVAL', 120);// 修改 WordPress 编辑器自动保存时间间隔为 120 秒保存一次
define('WP_POST_REVISIONS', 5);//仅保留保留 5 个最近修改，也可以减小此数字，但不能太低了
define('EMPTY_TRASH_DAYS', 7 );//7 天后自动清空回收站，这个自己根据情况设定
define( 'CORE_UPGRADE_SKIP_NEW_BUNDLED', true );//更新时跳过 wp-content 目录，增加更新效率

以上搬主题都做了注释了，如需使用则可以将相应的域名改为自己的域名，相应的主题改为自己的对应主题名称即可。比如第一条，由于很多原因你需要给站点指定 cookies 域。比较常见的就是阻止子域名上请求静态内容的 cookies 不必要的传输。这种情况下，你就可以使用此定义告知 WordPress 只向非静态域发送 cookies，这将会大大提高网站的性能。

四、设置数据库查询缓存及索引

一旦数据库比较大的话，开启数据库查询缓存，可以大幅降低CPU的使用，从而实现网站访问响应更快的效果。目前MySQL及MariaDB的数据库都支持查询缓存。

1、什么是MySQL查询缓存

MySQL查询缓存是MySQL中比较独特的一个缓存区域，用来缓存特定Query的整个结果集信息，且共享给所有客户端。为了提高完全相同的Query语句的响应速度，MySQL Server会对查询语句进行Hash计算后，把得到的hash值与Query查询的结果集对应存放在Query Cache中。当MySQL Server打开Query Cache之后，MySQL Server会对接收到的每一个SELECT 语句通过特定的Hash算法计算该Query的Hash值，然后通过该hashi值到Query Cache中去匹配。

如果没有匹配，将这个hash值存放在一个hash链表中，并将Query的结果集存放到cache中，存放hashi值链表的每个hash节点存放了相应Quey结果集在cache中的地址，以及该query所涉及到一些table相关信息；
如果通过hash值匹配到了一样的Query，则直接将cache中相应的Query结果集返回给客户端。

目前MySQL Query Cache只会cache select语句，其他类似show ，use的语句不会被cache MySQL 的每个Query Cache都是以SQL文本作为key来存储的，在应用Query Cache之前，SQL文本不会做任何处理。也就是说，两个SQL语句，只要相差哪怕一个字符(例如大小写不一样，多一个空格，多注释)，那么这两个SQL将使用不同的Cache地址。如: 下面三条SQL将会被存储在三个不同的缓存里，虽然他们的结果都是一样的。select * FROM people where name=’surfchen’; select * FROM people where /*hey~*/ name=’surfchen’; SELECT * FROM people where name=’surfchen’;

2、MySQL缓存机制

ySQL缓存机制简单的说就是缓存sql文本及查询结果，如果运行相同的SQL，服务器直接从缓存中取到结果，而不需要再去解析和执行SQL。如果表更改了，那么使用这个表的所有缓存查询将不再有效，查询缓存中值相关条目被清空。这里的更改指的是表中任何数据或是结构发生改变，包括INSERT、UPDATE、 DELETE、TRUNCATE、ALTER TABLE、DROP TABLE或DROP DATABASE等，也包括那些映射到改变了的表使用MERGE表的查询。显然，这对于频繁更新的表，查询缓存是不适合的，而对于一些不常改变数据且有大量相同SQL查询的表，查询缓存会节约很大的性能。

查询必须是完全相同(逐字节相同)才能够被认为是相同的。另外，同样的查询字符串由于其它原因可能认为是不同的。使用不同的数据库、不同的协议版本或者不同默认字符集的查询被认为是不同的查询并且分别进行缓存。

需要注意的是MySQL Query Cache 是对大小写敏感的，因为Query Cache 在内存中是以 HASH 结构来进行映射，HASH 算法基础就是组成 SQL 语句的字符，所以任何SQL语句的改变重新cache.

2.1 缓存规则

开启了缓存，MySQL Server会自动将查询语句和结果集返回到内存，下次再查直接从内存中取；
缓存的结果是通过sessions共享的，所以一个client查询的缓存结果，另一个client也可以使用
MySQL Query Cache内容为 select 的结果集, cache 使用完整的SQL字符串做 key, 并区分大小写，空格等。即两个SQL必须完全一致才会导致cache命中。即检查查询缓存时，MySQL Server不会对SQL做任何处理，它精确的使用客户端传来的查询，只要字符大小写或注释有点不同，查询缓存就认为是不同的查询；
prepared statement永远不会cache到结果，即使参数完全一样。在 5.1 之后会得到改善。
where条件中如包含任何一个不确定的函数将永远不会被cache, 比如current_date, now等。
date 之类的函数如果返回是以小时或天级别的，最好先算出来再传进去。
太大的result set不会被cache (< query_cache_limit)
MySQL缓存在分库分表环境下是不起作用的
执行SQL里有触发器,自定义函数时，MySQL缓存也是不起作用的

2.2 缓存失效

在表的结构或数据发生改变时，查询缓存中的数据不再有效。如INSERT、UPDATE、 DELETE、TRUNCATE、ALTER TABLE、DROP TABLE或DROP DATABASE会导致缓存数据失效。所以查询缓存适合有大量相同查询的应用，不适合有大量数据更新的应用。
一旦表数据进行任何一行的修改，基于该表相关cache立即全部失效。

2.3 手动清理缓存手动清理缓存可以使用下面三个SQL

FLUSH QUERY CACHE； #清理查询缓存内存碎片
RESET QUERY CACHE；#从查询缓存中移除所有查询
FLUSH TABLES； #关闭所有打开的表，同时该操作会清空查询缓存中的内容

2.4 缓存机制中的内存管理

MySQL Query Cache 使用内存池技术，自己管理内存释放和分配，而不是通过操作系统。内存池使用的基本单位是变长的block, 用来存储类型、大小、数据等信息；一个result set的cache通过链表把这些block串起来。block最短长度为query_cache_min_res_unit。

当服务器启动的时候，会初始化缓存需要的内存，是一个完整的空闲块。当查询结果需要缓存的时候，先从空闲块中申请一个数据块为参数query_cache_min_res_unit配置的空间，即使缓存数据很小，申请数据块也是这个，因为查询开始返回结果的时候就分配空间，此时无法预知结果多大。

分配内存块需要先锁住空间块，所以操作很慢，MySQL会尽量避免这个操作，选择尽可能小的内存块，如果不够，继续申请，如果存储完时有空余则释放多余的。

WordPress深度加速-OpenLiteSpeed环境下的WordPress数据库优化设置详细教程插图1

但是如果并发的操作，余下的需要回收的空间很小，小于query_cache_min_res_unit，不能再次被使用，就会产生碎片。如图：

WordPress深度加速-OpenLiteSpeed环境下的WordPress数据库优化设置详细教程插图2

3、查询缓存（Query Cache）

WordPress深度加速-OpenLiteSpeed环境下的WordPress数据库优化设置详细教程插图3

SQL语句
查询缓存
解析器
解析树
预处理
查找最好的查询路径
查询优化SQL语句
执行计划
API调用存储引擎
调用数据，返回结果缓存SELECT操作或预处理查询的结果集和SQL语句，当有新的SELECT语句或预处理查询语句请求，先去查询缓存，判断是否存在可用的记录集，判断标准：与缓存的SQL语句，是否完全一样，区分大小写。不需要对SQL语句做任何解析和执行，当然语法解析必须通过在先，直接从Query Cache中获得查询结果，提高查询性能查询缓存的判断规则，不够智能，也即提高了查询缓存的使用门槛，降低其效率；查询缓存的使用，会增加检查和清理Query Cache中记录集的开销

哪些查询可能不会被缓存：

查询语句中加了SQL_NO_CACHE参数；
查询语句中含有获得值的函数，包含自定义函数，如：NOW()、CURDATE()、GET_LOCK()、RAND()、CONVERT_TZ()等；
对系统数据库的查询：mysql、information_schema 查询语句中使用SESSION级别变量或存储过程中的局部变量；
查询语句中使用了LOCK IN SHARE MODE、FOR UPDATE的语句，查询语句中类似SELECT …INTO 导出数据的语句；
对临时表的查询操作；存在警告信息的查询语句；不涉及任何表或视图的查询语句；某用户只有列级别权限的查询语句；
事务隔离级别为Serializable时，所有查询语句都不能缓存。

查询缓存相关的服务器变量：

query_cache_min_res_unit: 查询缓存中内存块的最小分配单位，默认4k，较小值会减少浪费，但会导致更频繁的内存分配操作，较大值会带来浪费，会导致碎片过多，内存不足；
query_cache_limit：单个查询结果能缓存的最大值，默认为1M，对于查询结果过大而无法缓存的语句，建议使用SQL_NO_CACHE；
query_cache_size：查询缓存总共可用的内存空间；单位字节，必须是1024的整数倍，最小值40KB，低于此值有警报；
query_cache_wlock_invalidate：如果某表被其它的会话锁定，是否仍然可以从查询缓存中返回结果，默认值为OFF，表示可以在表被其它会话锁定的场景中继续从缓存返回数据；ON则表示不允许；
query_cache_type: 是否开启缓存功能，取值为ON, OFF, DEMAND，默认值为ON
- 值为OFF或0时，查询缓存功能关闭；
- 值为ON或1时，查询缓存功能打开，SELECT的结果符合缓存条件即会缓存，否则，不予缓存，显式指定SQL_NO_CACHE，不予缓存；
- 值为DEMAND或2时，查询缓存功能按需进行，显式指定SQL_CACHE的SELECT语句才会缓存；其它均不予缓存。

优化查询缓存：

WordPress深度加速-OpenLiteSpeed环境下的WordPress数据库优化设置详细教程插图4

查询缓存相关的状态变量：

Qcache_free_blocks：处于空闲状态 Query Cache中内存 Block 数；
Qcache_free_memory：处于空闲状态的 Query Cache 内存总量；
Qcache_hits：Query Cache 命中次数；
Qcache_inserts：向 Query Cache 中插入新的 Query Cache 的次数，即没有命中的次数；
Qcache_lowmem_prunes：当 Query Cache 内存容量不够，需要删除老的Query Cache 以给新的 Cache 对象使用的次数；
Qcache_not_cached：没有被 Cache 的 SQL 数，包括无法被 Cache 的 SQL 以及由于 query_cache_type 设置的不会被 Cache 的 SQL语句；
Qcache_queries_in_cache：在 Query Cache 中的 SQL 数量；
Qcache_total_blocks：Query Cache 中总的 Block。

4、MySQL Query Cache对性能的影响

WordPress深度加速-OpenLiteSpeed环境下的WordPress数据库优化设置详细教程插图5

如上图所示: 在MySQL Server中打开Query Cache对数据库的读和写都会带来额外的消耗:

1) 读查询开始之前必须检查是否命中缓存。
2) 如果读查询可以缓存，那么执行完查询操作后，会查询结果和查询语句写入缓存。
3) 当向某个表写入数据的时候，必须将这个表所有的缓存设置为失效，如果缓存空间很大，则消耗也会很大，可能使系统僵死一段时间，因为这个操作是靠全局锁操作来保护的。
4) 对InnoDB表，当修改一个表时，设置了缓存失效，但是多版本特性会暂时将这修改对其他事务屏蔽，在这个事务提交之前，所有查询都无法使用缓存，直到这个事务被提交，所以长时间的事务，会大大降低查询缓存的命中

MySQL Query Cache碎片优化

WordPress深度加速-OpenLiteSpeed环境下的WordPress数据库优化设置详细教程插图6

如上图所示，没有什么办法能够完全避免碎片，但是选择合适的query_cache_min_res_unit可以帮你减少由碎片导致的内存空间浪费。这个值太小，则浪费的空间更少，但是会导致频繁的内存块申请操作；如果设置得太大，那么碎片会很多。调整合适的值其实是在平衡内存浪费和CPU消耗。可以通过内存实际消耗（query_cache_size – Qcache_free_memory）除以Qcache_queries_in_cahce计算单个查询的平均缓存大小。可以通过Qcahce_free_blocks来观察碎片。

通过FLUSH_QUERY_CAHCE完成碎片整理，这个命令将所有的查询缓存重新排序，并将所有的空闲空间都聚焦到查询缓存的一块区域上。

5、数据库索引

索引是特殊数据结构：定义在查找时作为查找条件的字段，索引实现在存储引擎。

索引可以降低服务需要扫描的数据量，减少了IO次数
索引可以帮助服务器避免排序和使用临时表
索引可以帮助将随机I/O转为顺序I/O
但是占用额外空间，影响插入速度

1、索引类型：

WordPress深度加速-OpenLiteSpeed环境下的WordPress数据库优化设置详细教程插图7

B + Tree 索引：顺序存储，每一个叶子节点到根的距离都是相同的，左前缀索引，适合查询范围类的数据；
- 适合使用B-Tree索引的查询类型
  – 全值匹配
  – 匹配最左前缀
  – 匹配范围值
  – 精确匹配某一列并范围匹配另一列（复合索引）
  – 只访问索引的查询
- 不适合使用B-tree索引的查询类型
  – 不从最左列开始
  – 不能跳过索引中的列
  – 如果查询中某个列是为范围查询那么右侧的列无法再使用索引优化查询
Hash索引：基于哈希表，构建出键值对的索引，特别适用于精确匹配索引中的索引列，只支持等值比较查询（IN，=，<>）；不适合于顺序查询，不支持模糊匹配；只有Memory存储引擎支持显式Hash索引
空间索引（R – Tree）：只有MyISAM支持空间索引
全文索引（FULL TEXT）：在文本中查找关键词

2、高性能索引策略：

独立使用列，尽量避免其参与运算
使用左前缀索引：索引构建于字段的左侧的多少字符要通过索引选择性来评估；索引选择性：不重复的索引值和数据表的记录总数的比值
多列索引：AND操作时更适合使用多列索引，而非为每个列创建单独的索引
选择合适的索引列次序：无排序和分组时，将选择性最高放左侧

3、索引的优化建议

只要列中含有NULL值，就最好不要在此例设置索引，复合索引如果有NULL值，此列在使用时也不会使用索引
尽量使用短索引，如果可以，应该制定一个前缀长度
对于经常在where子句使用的列，最好设置索引
对于有多个列where或者order by子句，应该建立复合索引
对于like语句，以%或者‘-’开头的不会使用索引，以%结尾会使用索引
尽量不要在列上进行运算（函数操作和表达式操作）
尽量不要使用not in和<>操作
多表连接时，尽量小表驱动大表，即小表 join 大表
在千万级分页时使用limit
对于经常使用的查询，可以开启缓存
大部分情况连接效率远大于子查询

6、开启数据库查询缓存及索引

说了这么多，那么如何开启数据库查询缓存呢。其实很简单，一般MySQL数据库，找到my.cnf文件。

一般登陆服务器后，输入如下代码：

vi /etc/my.cnf

打开后，找到如下的代码，进行编辑：

query_cache_size = 20M
query_cache_type = ON

query_cache_size = 20M的意思表示查询缓存的大小设置，query_cache_type = ON的意思表示开启查询缓存

注意：键盘点击 I 后就可以编辑，编辑后先按 esc 退出键，然后输入 :wq 回车即可保存。

如果是MariaDB数据库，那问题来了，my.cnf文件里面什么都没有，如下图

WordPress深度加速-OpenLiteSpeed环境下的WordPress数据库优化设置详细教程插图8

其实里面代码有包含my.cnf.d文件夹下的相应cnf文件配置，但是就算进入了my.cnf.d文件夹，分别打开里面的文件，都没有相应的配置可以进行更改。这个时候怎么办？

不用担心，因为MariaDB数据库如果没有进行设置，则自动取默认配置。这个我们不用管，其实我们可以直接在my.cnf文件里增加代码即可。

[mysqld]
skip-external-locking
query_cache_size = 20M
query_cache_type = ON
key_buffer_size = 16M
max_allowed_packet = 1M
table_open_cache = 64
sort_buffer_size = 512K
net_buffer_length = 8K
read_buffer_size = 256K
read_rnd_buffer_size = 512K
myisam_sort_buffer_size = 8M
max_connections = 256

以上的代码解释如下：

[mysqld]
skip-external-locking
#避免 MySQL 的外部锁定，减少出错几率增强稳定性。

key_buffer_size = 16M
#指定用于索引的缓冲区大小，增加它可得到更好的索引处理性能。16M适用于 512MB内存，对于内存在4GB左右的服务器该参数可设置为256M，依此类推即可。注意：该参数值设置的过大反而会是服务器整体效率降低！

max_allowed_packet = 1M
#MySQL 根据此配置会限制 server 接受的数据包大小。

table_open_cache = 64
#指定表高速缓存的大小。每当MySQL访问一个表时，如果在表缓冲区中还有空间，该表就被打开并放入其中，这样可以更快地访问表内容。注意，不能盲目地把table_open_cache设置成很大的值。如果设置得太高，可能会造成文件描述符不足，从而造成性能不稳定或者连接失败。
64 适用于 512MB 内存，1GB 内存则可以设置成 128，依此类推即可。

sort_buffer_size = 512K
#查询排序时所能使用的缓冲区大小。注意：该参数对应的分配内存是每连接独占，如果有100个连接，那么实际分配的总共排序缓冲区大小为100 × 512K ＝ 50MB。
512K 适用于 512MB 内存，1GB 内存则可以设置成 1M，依此类推即可。

net_buffer_length = 8K
#初始化server 接受的数据包大小，当需要的时候再由 max_allowed_packet 控制增长的大小。注意：该参数值设置的范围只能为1 – 1024K。

read_buffer_size = 256K
#读查询操作所能使用的缓冲区大小。和 sort_buffer_size 一样，该参数对应的分配内存也是每连接独享。
256K 适用于 512MB 内存，1GB 内存则可以设置成 512K，依此类推即可。

read_rnd_buffer_size = 512K
#查询操作多表所能使用的缓冲区大小。设置较大的值可以有效提升 ORDER BY 的性能。和 sort_buffer_size 一样，该参数对应的分配内存也是每连接独享。
512K适用于 512MB 内存，1GB 内存则可以设置成 1M，依此类推即可。

myisam_sort_buffer_size = 8M
#MyISAM 排序所能使用的缓冲区大小。
8M 适用于 512MB 内存，1GB 内存则可以设置成 16M，依此类推即可。

max_connections = 256
#指定MySQL允许的最大连接进程数。如果在访问时经常出现 Too Many Connections 的错误提示，则需要增大该参数值。
注意：该参数默认值为 151，最大可以设置为 100000
这里建议设置成内存的一半，比如 512MB 内存就设置成 256，依此类推。

以上设置完后，记得重启数据库让其生效。重启数据库命令如下：

systemctl restart mysqld.service

7、查询缓存是否启用生效

以上设置好后，如何知道是否生效呢？这里以MariaDB数据库为例，我们需要登陆数据库进行操作。搬主题的是CyberPanel面板，因此首先要了解相应的数据库登陆密码。

输入如下命令获取数据库密码：

cat /etc/CyberPanel/mysqlPassword

WordPress深度加速-OpenLiteSpeed环境下的WordPress数据库优化设置详细教程插图9

其中红色框里面的就是对应的数据库登陆密码。

然后输入命令进行登陆

mysql -u root -p

WordPress深度加速-OpenLiteSpeed环境下的WordPress数据库优化设置详细教程插图10

然后要求输入密码，这个时候将对应的密码输入，回车即可登陆相应的数据库。

WordPress深度加速-OpenLiteSpeed环境下的WordPress数据库优化设置详细教程插图11

输入命令查询

show variables like '%query_cache%';

WordPress深度加速-OpenLiteSpeed环境下的WordPress数据库优化设置详细教程插图12

其中query_cache_type:NO代表已经开启查询缓存

再输入命令查询缓存的命中率

show status like 'qcache%';

WordPress深度加速-OpenLiteSpeed环境下的WordPress数据库优化设置详细教程插图13

其实以上的各种设置，仅供参考，各位可以根据自己的实际情况进行增减和修改。

五、利用数据库工具检测进行优化

以上搬主题也只列了一部分可以优化的数据库内容，但是如何设置相应的值，很多小伙伴也不是很明白。这个时候我们可以借助一个免费的数据库检测优化工具来帮助我们。

这个工具就是mysqltuner，它支持MySQL和MariaDB数据库。

先下载数据库测试工具

wget http://mysqltuner.pl/ -O mysqltuner.pl

下载完成后，输入如下指令进行检测：

perl mysqltuner.pl

然后又要再分别输入数据库的用户名和密码，用户名填：root ，密码继续用上面的方法获取，然后输入。

WordPress深度加速-OpenLiteSpeed环境下的WordPress数据库优化设置详细教程插图14

接下来会生成一大堆的检测报告，这个时候我们可以看到最下面的性能优化建议。如类似这样的：

*** Add RAM before increasing MySQL buffer variables ***
    performance_schema = ON enable PFS
    innodb_log_file_size should be (=64M) if possible, so InnoDB total log files size equals to 25% of buffer pool size.

其中的意思performance_schema = ON建议开启，innodb_log_file_size的大小值建议至少需要64M。我们只需将对应的建议在my.cnf中添加和修改即可。

比如将innodb_log_file_size=64M加入my.cnf文件里。如果之前有则直接修改。

六、数据库优化总结

其实通过以上的数据库优化后，站点的速度能有一定的提升。但是每个网站的流量、架构、主题、插件各方面都不一样，需要在后面的过程中不断的优化和调整，才能直接满足WordPress的实际站点的使用。因此建议不断调优。

其实还有一个很大的争议点，就是数据库查询缓存的启用和禁用。本篇文章虽然介绍了开启数据库查询缓存的方法及优化设置，但是网上的结论分为开启和禁用两各派系。到底开启后对性能的提升有多大，是利大于弊还是弊大于利，各位小伙伴自己可以尝试。

这里搬主题给个开启还是关闭数据库查询缓存的建议：如果是BBS论坛，或者商城等互动频繁，写入数据更新快的站点，禁用查询缓存最佳。如果是WordPress站点，更新不频繁，比如2-3天更新一次甚至更长，那么建议开启查询缓存。如果是每天都更新，一次更新几十上百篇的WordPress站点，建议禁用。

最终实际体验，还是自己去测试吧。

① 本站文章均为原创，除非另有说明，否则本站内容依据CC BY-NC-SA 4.0许可证进行授权，转载请附上出处链接，谢谢。
② 本站提供的资源(插件或主题)均为网上搜集，如有涉及或侵害到您的版权请立即通知我们。
③ 本站所有下载文件，仅用作学习研究使用，请下载后24小时内删除，支持正版，勿用作商业用途。
④ 因代码可变性，不保证兼容所有浏览器、不保证兼容所有版本的WP、不保证兼容您安装的其他插件。
⑤ 本站保证所提供资源(插件或主题)的完整性，但不含授权许可、帮助文档、XML文件、PSD、后续升级等。
⑥ 使用该资源(插件或主题)需要用户有一定代码基础知识！另本站提供汉化使用安装教程，仅供参考。由本站提供的资源对您的网站或计算机造成严重后果的本站概不负责。
⑦ 有时可能会遇到部分字段无法汉化，同时请保留作者汉化宣传信息，谢谢！
⑧ 本站资源售价只是赞助和汉化辛苦费，收取费用仅维持本站的日常运营所需。
⑨ 如果喜欢本站资源，欢迎捐助本站开通会员享受优惠折扣，谢谢支持！
⑩ 如果网盘地址失效，请在相应资源页面下留言，我们会尽快修复下载地址。

THE END