MySQL针对Discuz论坛程序的基本优化教程

过了这么久,discuz论坛的问题还是困扰着很多网友,其实从各论坛里看到的问题总结出来,很关键的一点都是因为没有将数据表引擎转成InnoDB导致的,discuz在并发稍微高一点的环境下就表现的非常糟糕,产生大量的锁等待,这时候如果把数据表引擎改成InnoDB的话,我相信会好很多。这次就写个扫盲贴吧。

1. 启用innodb引擎,并配置相关参数

#skip-innodb
innodb_additional_mem_pool_size = 16M #一般16M也够了,可以适当调整下
innodb_buffer_pool_size = 6G #如果是专用db的话,一般是内存总量的80%
innodb_data_file_path = ibdata1:1024M:autoextend
innodb_file_io_threads = 4
innodb_thread_concurrency = 20
innodb_flush_log_at_trx_commit = 1
innodb_log_buffer_size = 16M
innodb_log_file_size = 256M
innodb_log_files_in_group = 3
innodb_max_dirty_pages_pct = 50
innodb_lock_wait_timeout = 120
innodb_file_per_table

修改表引擎为innodb:

mysql> alter table cdb_access engine = innodb;

其他表类似上面,把表名换一下即可...
将表存储引擎改成innodb后,不仅可以避免大量的锁等待,还可以提升查询的效率,因为innodb会把data和index都放在buffer pool中,效率更高。

2.缓存优化
在 my.cnf 中添加/修改以下选项:

 #取消文件系统的外部锁
skip-locking
#不进行域名反解析,注意由此带来的权限/授权问题
skip-name-resolve
#索引缓存,根据内存大小而定,如果是独立的db服务器,可以设置高达80%的内存总量
key_buffer = 512M
#连接排队列表总数
back_log = 200
max_allowed_packet = 2M
#打开表缓存总数,可以避免频繁的打开数据表产生的开销
table_cache = 512
#每个线程排序所需的缓冲
sort_buffer_size = 4M
#每个线程读取索引所需的缓冲
read_buffer_size = 4M
#MyISAM表发生变化时重新排序所需的缓冲
myisam_sort_buffer_size = 64M
#缓存可重用的线程数
thread_cache = 128
#查询结果缓存
query_cache_size = 128M
#设置超时时间,能避免长连接
set-variable = wait_timeout=60
#最大并发线程数,cpu数量*2
thread_concurrency = 4
#记录慢查询,然后对慢查询一一优化
log-slow-queries = slow.log
long_query_time = 1
#关闭不需要的表类型,如果你需要,就不要加上这个
skip-bdb

以上参数根据各自服务器的配置差异进行调整,仅作为参考.

3.索引优化
上面提到了,已经开启了慢查询,那么接下来就要对慢查询进行逐个优化了.

搜索的查询SQL大致如下:

 SELECT t.* FROM cdb_posts p, cdb_threads t WHERE
t.fid IN ('37', '45', '4', '6', '17', '41', '28', '32', '31', '1', '42')
AND p.tid=t.tid AND p.author LIKE 'JoansWin'
GROUP BY t.tid ORDER BY lastpost DESC LIMIT 0, 80;

用 EXPLAIN 分析的结果如下:

 mysql>EXPLAIN SELECT t.* FROM cdb_posts p, cdb_threads t WHERE
t.fid IN ('37', '45', '4', '6', '17', '41', '28', '32', '31', '1', '42')
AND p.tid=t.tid AND p.author LIKE 'JoansWin'
GROUP BY t.tid ORDER BY lastpost DESC LIMIT 0, 80;
+-----------+------------+----------+--------------+-------------+-----------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref   | rows | Extra
+-----------+------------+----------+--------------+-------------+-----------+-------------+
| 1 | SIMPLE  | t  | range | PRIMARY,fid | fid | 2  | NULL  | 66160 | Using where;
Using temporary; Using filesort |
| 1 | SIMPLE  | p  | ref | tid   | tid | 3  | Forum.t.tid | 10 | Using where
| +----+-------------+-------+-------+---------------+------+---------+-------------+-------+
---------

只用到了 t.fid 和 p.tid,而 p.author 则没有索引可用,总共需要扫描
66160*10 = 661600 次索引,够夸张吧 :(
再分析 cdb_threads 和 cdb_posts 的索引情况:

 mysql>show index from cdb_posts;
+-----------+------------+----------+--------------+-------------+-----------+----------
---+----------+--------+------+--+
| Table  | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part |
Packed | Null | Index_type | Comment | +-----------+------------+----------+--------------+----
---------+-----------+-------------+----------+--------+------+--+
| cdb_posts |   0 | PRIMARY |   1 | pid   | A   |  680114 |  NULL | NULL |
| BTREE  |   |
| cdb_posts |   1 | fid  |   1 | fid   | A   |   10 |  NULL | NULL |
| BTREE  |   |
| cdb_posts |   1 | tid  |   1 | tid   | A   |  68011 |  NULL | NULL |
| BTREE  |   |
| cdb_posts |   1 | tid  |   2 | dateline | A   |  680114 |  NULL | NULL |
| BTREE  |   |
| cdb_posts |   1 | dateline |   1 | dateline | A   |  680114 |  NULL | NULL |
| BTREE  |   |
+-----------+------------+----------+--------------+-------------+-----------+---

以及

 mysql>show index from cdb_threads;
+-----------+------------+----------+--------------+-------------+-----------+-------------+
----------+--------+------+-----+
| Table  | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part |
Packed | Null | Index_type | Comment | +-----------+------------+----------+--------------+-----
--------+-----------+-------------+----------+--------+------+-----+
| cdb_threads |   0 | PRIMARY |   1 | tid   | A   |  68480 |  NULL | NULL |
| BTREE  |   |
| cdb_threads |   1 | lastpost |   1 | topped  | A   |   4 |  NULL | NULL |
| BTREE  |   |
| cdb_threads |   1 | lastpost |   2 | lastpost | A   |  68480 |  NULL | NULL |
| BTREE  |   |
| cdb_threads |   1 | lastpost |   3 | fid   | A   |  68480 |  NULL | NULL |
| BTREE  |   |
| cdb_threads |   1 | replies |   1 | replies  | A   |   233 |  NULL | NULL |
| BTREE  |   |
| cdb_threads |   1 | dateline |   1 | dateline | A   |  68480 |  NULL | NULL |
| BTREE  |   |
| cdb_threads |   1 | fid  |   1 | fid   | A   |   10 |  NULL | NULL |
| BTREE  |   |
| cdb_threads |   1 | enablehot |   1 | enablehot | A   |   2 |  NULL | NULL |
| BTREE  |   | +-------------+------------+-----------+--------------+-------------+------

看到索引 fid 和 enablehot 基数太小,看来该索引完全没必要,不过,对于fid基数较大的情况,则可能需要保留>该索引.
所做修改如下:

 ALTER TABLE `cdb_threads` DROP INDEX `enablehot`, DROP INDEX `fid`, ADD INDEX (`fid`, `lastpost`);
ALTER TABLE `cdb_posts` DROP INDEX `fid`, ADD INDEX (`author`(10));
OPTIMIZE TABLE `cdb_posts`;
OPTIMIZE TABLE `cdb_threads`;

在这里, p.author 字段我设定的部分索引长度是 10, 是我经过分析后得出来的结果,不同的系统,这里的长度也不同,最好自己先取一下平均值,然后再适当调整.
现在,再来执行一次上面的慢查询,发现时间已经从 6s 变成 0.19s,提高了 30 倍.

(0)

相关推荐

  • MySQL中对表连接查询的简单优化教程

    在MySQL中,A LEFT JOIN B join_condition执行过程如下: · 根据表A和A依赖的所有表设置表B. · 根据LEFT JOIN条件中使用的所有表(除了B)设置表A. · LEFT JOIN条件用于确定如何从表B搜索行.(换句话说,不使用WHERE子句中的任何条件). · 可以对所有标准联接进行优化,只是只有从它所依赖的所有表读取的表例外.如果出现循环依赖关系,MySQL提示出现一个错误. · 进行所有标准WHERE优化. · 如果A中有一行匹配WHERE子句,但B中没

  • MySQL常见的底层优化操作教程及相关建议

    1.硬件层相关优化 1.1.CPU相关 在服务器的BIOS设置中,可调整下面的几个配置,目的是发挥CPU最大性能,或者避免经典的NUMA问题: (1).选择Performance Per Watt Optimized(DAPC)模式,发挥CPU最大性能,跑DB这种通常需要高运算量的服务就不要考虑节电了: (2).关闭C1E和C States等选项,目的也是为了提升CPU效率: (3).Memory Frequency(内存频率)选择Maximum Performance(最佳性能): (4).内

  • MySQL针对Discuz论坛程序的基本优化教程

    过了这么久,discuz论坛的问题还是困扰着很多网友,其实从各论坛里看到的问题总结出来,很关键的一点都是因为没有将数据表引擎转成InnoDB导致的,discuz在并发稍微高一点的环境下就表现的非常糟糕,产生大量的锁等待,这时候如果把数据表引擎改成InnoDB的话,我相信会好很多.这次就写个扫盲贴吧. 1. 启用innodb引擎,并配置相关参数 #skip-innodb innodb_additional_mem_pool_size = 16M #一般16M也够了,可以适当调整下 innodb_b

  • Linux+Nginx+MySQL下配置论坛程序Discuz的基本教程

    Crossday Discuz! Board(简称 Discuz!)是北京康盛新创科技有限责任公司推出的一套通用的社区论坛软件系统.自2001年6月面世以来,Discuz!已拥有14年以上的应用历史和200多万网站用户案例,是全球成熟度最高.覆盖率最大的论坛软件系统之一.目前最新版本Discuz! X3.2正式版于2015年6月9日发布,首次引入应用中心的开发模式.2010年8月23日,康盛创想与腾讯达成收购协议,成为腾讯的全资子公司. Crossday Discuz! Board(以下简称 D

  • MySQL中insert语句的使用与优化教程

    MySQL 表中使用 INSERT INTO SQL语句来插入数据. 你可以通过 mysql> 命令提示窗口中向数据表中插入数据,或者通过PHP脚本来插入数据. 语法 以下为向MySQL数据表插入数据通用的 INSERT INTO SQL语法: INSERT INTO table_name ( field1, field2,...fieldN ) VALUES ( value1, value2,...valueN ); 如果数据是字符型,必须使用单引号或者双引号,如:"value"

  • MySQL优化配置文件my.ini(discuz论坛)

    在Apache, PHP, MySQL的体系架构中,MySQL对于性能的影响最大,也是关键的核心部分.对于Discuz!论坛程序也是如此,MySQL的设置是否合理优化,直接影响到论坛的速度和承载量!同时,MySQL也是优化难度最大的一个部分,不但需要理解一些MySQL专业知识,同时还需要长时间的观察统计并且根据经验进行判断,然后设置合理的参数. 下面我们了解一下MySQL优化的一些基础,MySQL的优化我分为两个部分,一是服务器物理硬件的优化,二是MySQL自身(my.cnf)的优化. 一.服务

  • 千万级记录的Discuz论坛导致MySQL CPU 100%的优化笔记

    发现此主机运行了几个 Discuz 的论坛程序, Discuz论坛的好几个表也存在着这个问题.于是顺手一并解决,cpu占用再次降下来了. 前几天,一位朋友通过这篇文章找到了我,说他就是运行最新的 discuz 版本,MySQL 占用 CPU 100%,导致系统假死,每天都要重启好几次,花了一个多月的时间一直没有解决,希望我帮忙一下.经过检查,他的这个论坛最重要的几个表中,目前 cdb_members 表,有记录 6.2 万:cdb_threads 表,有记录 11万:cdb_posts表,有记录

  • 由于mysql运行权限导致无法找到 Discuz! 论坛数据表! 的解决方法

    无法找到 Discuz! 论坛数据表! 在5.5升级到6.0时,上传完后,运行http://*****.com/upgrade9.php 时出下下列问题: 无法找到 Discuz! 论坛数据表! 请修改 config.inc.php 当中关于数据库的设置,然后上传到论坛目录,重新开始升级 config.inc.php 这个文件我用的是以前的,应该没有问题的. 解决方法:刷新N次,就好了.真是不明白为什么. 发现了,原理mysql的权限是普通用户权限,我们可以先将权限设为系统帐户,问题就可以解决了

  • Mysql占用过高CPU时的优化手段(必看)

    Mysql占用CPU过高的时候,该从哪些方面下手进行优化? 占用CPU过高,可以做如下考虑: 1)一般来讲,排除高并发的因素,还是要找到导致你CPU过高的哪几条在执行的SQL,show processlist语句,查找负荷最重的SQL语句,优化该SQL,比如适当建立某字段的索引: 2)打开慢查询日志,将那些执行时间过长且占用资源过多的SQL拿来进行explain分析,导致CPU过高,多数是GroupBy.OrderBy排序问题所导致,然后慢慢进行优化改进.比如优化insert语句.优化group

  • 国外著名论坛程序IPB(Invision Power Board)在nginx下的配置示例

    Invision Power Board (IPB)是一个论坛程序,基于php+MySQL. 虽然国内大部分都在用discuz,但是国外ipb的用户很多,今天贴出ipb的nginx配置文件.配置如下: 复制代码 代码如下: server { access_log off;  error_log logs/bbs.jb51.net-error_log warn; listen 80;  server_name bbs.jb51.net; # static file configuration  l

  • mysql配置连接参数设置及性能优化

    目录 1 前言 2 数据库连接配置信息 3 配置信息说明 4 数据库sql 5 mysql 性能优化的关注点 6 硬件和操作系统方面的优化 7 架构设计方面的优化 8 mysql 程序配置优化. 9 sql 执行层面优化 10 最终总结 1 前言 在java开发中,最常用的数据存储就是数据库,其中常用的就是mysql,关于数据库的连接配置信息,可能就不是那么的清除了,这里做一个配置信息的说明. 2 数据库连接配置信息 jdbc:mysql://localhost:3306/database_na

随机推荐