Discuz论坛数据库优化后变慢如何解决

简单来说就是数据库优化出了问题导致论坛速度变慢。
可能的原因有：
1 使用索引太多，更新表太慢。
2 、MySQL配置不正确。
这是一个严重的问题吗？ 3 、编写SQL语句复杂、效率低。
4 、硬件不足导致读写速度太慢。

解决方案：
1 如果您使用多个标签。
删除不需要读取的标签并仅保存密钥。
2 、MySQL配置不正确。
调整内存和临时表大小等参数。
3 、SQL语句写起来比较复杂，要简化，使用索引。
4 .如果硬件不足。
升级硬盘、CPU等硬件。

从诊断开始；查看慢查询日志；使用EXPLAIN分析SQL；监控资源使用情况。
然后逐步改进 首先解决最显着的慢点并升级硬件以确保底线。
这样论坛的速度就可以恢复了。
首先亲自看看这个。

图文结合带你搞懂MySQL日志之Slow Query Log（慢查询日志）

检查缓慢的 SQL 日志记录超时。
默认超时为 1 0 秒。
配置位于 my.cnf 中。
long_query_time 设置阈值。
switch_query_slow_log。
Slow_query_log 文件路径。
log-queries-not-use-indexes 不带索引的日志。
min_examined_row_limit 扫描的行数。
GreatSQL的字段更加丰富。
mysqldumpslow分析工具。
高级分析 pt-query-digest。
备份日志然后关闭它。
GreatSQL 是稳定且可选的。

阿里巴巴工程师教你认识mysql慢查询

查询慢的主要原因是需要扫描的行太多或索引无效。

常见原因： 1 .应用程序一次可以查询2 0000行以上数据。
计划分页2 0000块数据，2 0个线程同时处理，触发FullGC。
2 .标签设计不合逻辑。
无效索引会导致表回退并使扫描的行数增加一倍。
有些查询错过了完整的索引表扫描，这需要 5 00 毫秒。
3 .并发和低效的SQL。
当 1 0ms SQL 查询达到 5 00 个并发请求时，CPU 利用率会增加到 8 5 %。

故障排除程序： 1 .解释分析。
您必须更改 type=ALL 或 Extra=Usingfilesort。
2 . 监控扫描线数。
如果扫描线数>1 000；无需检查。
3 .检查执行时间。
2 00ms以上应该进行优化。

优化方向： 1 . 盖上标签。
封装索引可以减少7 0%的IO开销。
2 .分页优化。
限制偏移量；大小更改为 WHERE id>last_id。
3 . 缓存热点。
Redis对热点数据的缓存率超过8 0%。

实用注意：首先监控扫描行数，看索引 ရှင်းပြပါ။

MySQL运行一段时间后各种操作变很慢,重启后问题依旧,什么原因

老实说，这个问题要看具体的业务情况。
如果你问我如何诊断数据库性能问题，我会给你一些实用的观点。

1 .首先，让我们看看数据库负载。
您可以使用以下命令进行检查： B. SHOW GLOBAL STATUS LIKE 'Questions';这使您可以实时了解有多少 I/O 正在写入和轮询。
例如，上次检查时，我注意到一个电子商务系统在晚上 8 :00 到晚上 8 :00 之间经历了极高的写入量。
晚上 1 0:00然后我一定要检查一下是否是因为升职。

2 查询速度慢？打开慢查询日志。
Slow_query_log = 1 ;这个东西可以告诉你哪些SQL语句特别耗时。
我记得有一次检查一个旧系统，发现几千年来没有改变的查询速度慢得离谱。
原来是表数据量太大，根本就没有索引。
需要检查内存命中率。
状态表中有两个指标：Innodb_buffer_pool_read_requests和Innodb_buffer_pool_read命中率。
如果它们都是 1 00%，那就意味着基本上所有内容都在内存中。

3 您必须等待数据库重新启动。
重启后，内存缓存将被彻底清除，需要等待数据慢慢预热。
我见过的最夸张的事情是，系统在重启后实际上要等待半个小时才能正常运行，因为在重启之前缓存了太多异常数据。
如果此时查看监控，就会发现CPU这么高，是因为它在拼命读磁盘。

4 真的慢得离谱吗？检查磁盘负载。
您可以使用 iostat -mx 命令查看它。
我记得有一次检查系统，发现硬盘实际上是机械硬盘。
突然来了很多车流，立刻就被挤满了。
结果，CPU 已满并等待 I/O。
此时虽然重启暂时解决了问题，但后来更换SSD就完全解决了。

5 重新启动和重新安装只是临时解决方案。
例如，我上次遇到过一个系统。
重装后几天就好了。
原来是代码逻辑有问题，每次都没有用。
这个时候你就需要开始创业了。
例如，当我们检查用户行为时，我们发现 9 0% 的用户搜索相同的产品。
那么为什么不直接添加一个缓存表呢？
6 需要添加索引。
我见过的最尴尬的事情就是有人用 NOT IN 检查几十万条数据，结果 SQL 慢得要命。
直接添加索引速度快1 0倍。
此类SQL可以在慢查询日志中看到。

7 写突发IO比较困难。
比如上次检查直播系统，发现高峰期直接写满了磁盘。
结果，慢查询日志里充满了“写入超时”。
此时需要检查网络、存储和磁盘I/O。
后来发现CDN回源有问题，就改变策略，一切就好了。

8 需要创建缓存表。
我见过的最不可思议的就是，一个游戏系统居然用Redis来存储玩家装备表，但是当玩家登录的时候，Redis就直接被炸了。
后来我改用本地缓存+Redis二级缓存来处理这个问题。

简而言之，需要先检查利用率，然后再检查慢查询。
检查完毕后，根据情况添加索引并创建缓存表。
如果还是不行，再检查一下写IO。
一步一步来，不要着急。