页面底部的查询时间变长了要如何优化？另外看了下慢查询记录里有个表请求时间很久是缺少索引吗？ New

𝕷𝖎𝖑𝖏𝖆𝖈𝖐 · 发表于 2023-12-11 19:16:32

马上注册，免费下载更多dz插件网资源。

您需要登录才可以下载或查看，没有账号？立即注册

×

比如Dismall网站底部的处理时间是0.03秒左右，我们之前最快也差不多，现在变成了0.07秒左右，不知道是哪里设置没优化好还是数据库问题，已经启用Redis
页面底部的查询时间变长了要如何优化？另外看了下慢查询记录里有个表请求时间很久是缺少索引吗？
New
ANDt,SETtimestamp,time,SELECTDISTINCTt,localhostId

页面底部的查询时间变长了要如何优化？另外看了下慢查询记录里有个表请求时间很久是缺少索引吗？
New
ANDt,SETtimestamp,time,SELECTDISTINCTt,localhostId

另外慢查询里发现两个表的时间比较久，表是innodb引擎，请问是那里问题？

# Time: 2023-12-11T10:52:54.556741Z# User@Host: root[root] @ localhost [127.0.0.1] Id: 364698# Query_time: 4.171622 Lock_time: 0.000000 Rows_sent: 6 Rows_examined: 629667SET timestamp=1702291974;SELECT DISTINCT t.*, ti.attachment as attachmenturl, ti.remote FROM `pre_forum_thread` t INNER JOIN `pre_forum_threadimage` ti ON t.tid=ti.tid WHERE t.readperm='0' AND t.fid IN ('37','36','2') AND t.isgroup='0' AND t.displayorder>='0' ORDER BY t.dateline DESC LIMIT 0,6;# Time: 2023-12-11T10:52:55.744347Z# User@Host: root[root] @ localhost [127.0.0.1] Id: 364782# Query_time: 1.078406 Lock_time: 0.000000 Rows_sent: 6 Rows_examined: 156282SET timestamp=1702291975;SELECT DISTINCT t.*, ti.attachment as attachmenturl, ti.remote FROM `pre_forum_thread` t INNER JOIN `pre_forum_threadimage` ti ON t.tid=ti.tid WHERE t.readperm='0' AND t.fid IN ('37') AND t.isgroup='0' AND t.displayorder>='0' ORDER BY t.dateline DESC LIMIT 0,6;# Time: 2023-12-11T10:54:16.983359Z# User@Host: root[root] @ localhost [127.0.0.1] Id: 366522# Query_time: 1.254606 Lock_time: 0.000000 Rows_sent: 10 Rows_examined: 397061SET timestamp=1702292056;SELECT DISTINCT t.* FROM `pre_forum_thread` t WHERE t.readperm='0' AND t.fid IN ('82','40','41','44','43','45','63','39','87','64','51','52','88','56','48','57','59','61','60','66','67','68','70','71','72','74','76','93','79') AND t.isgroup='0' AND t.displayorder>='0' ORDER BY t.dateline DESC LIMIT 0,10;# Time: 2023-12-11T10:54:18.474966Z# User@Host: root[root] @ localhost [127.0.0.1] Id: 366548# Query_time: 1.226406 Lock_time: 0.000000 Rows_sent: 10 Rows_examined: 397061SET timestamp=1702292058;SELECT DISTINCT t.* FROM `pre_forum_thread` t WHERE t.readperm='0' AND t.fid IN ('37','36','2') AND t.special IN ('0') AND t.isgroup='0' AND t.displayorder>='0' ORDER BY t.dateline DESC LIMIT 0,10;# Time: 2023-12-11T10:56:56.033320Z# User@Host: root[root] @ localhost [127.0.0.1] Id: 369432# Query_time: 1.996411 Lock_time: 0.001000 Rows_sent: 3 Rows_examined: 397108SET timestamp=1702292216;SELECT DISTINCT t.*, ti.attachment as attachmenturl, ti.remote FROM `pre_forum_thread` t INNER JOIN `pre_forum_threadimage` ti ON t.tid=ti.tid WHERE t.readperm='0' AND t.fid IN ('48') AND t.isgroup='0' AND t.dateline >= '1701687413' AND t.displayorder>='0' ORDER BY t.recommends DESC LIMIT 0,3;# Time: 2023-12-11T10:57:06.324541Z# User@Host: root[root] @ localhost [127.0.0.1] Id: 369624# Query_time: 2.121604 Lock_time: 0.000000 Rows_sent: 3 Rows_examined: 397222SET timestamp=1702292226;SELECT DISTINCT t.*, ti.attachment as attachmenturl, ti.remote FROM `pre_forum_thread` t INNER JOIN `pre_forum_threadimage` ti ON t.tid=ti.tid WHERE t.readperm='0' AND t.fid IN ('51','52','88') AND t.isgroup='0' AND t.dateline >= '1701687424' AND t.displayorder>='0' ORDER BY t.recommends DESC LIMIT 0,3;

复制代码

我知道答案回答被采纳将会获得1 贡献已有0人回答

©DZ插件网所发布的一切资源仅限用于学习和研究目的；不得将上述内容用于商业或者非法用途，否则，一切后果请用户自负。
本站内容为站长个人技术研究记录或网络，不提供用户交互功能，所有内容版权归原作者所有。您必须在下载后的24个小时之内，从您的电脑中彻底删除上述内容。如果您喜欢该程序，请支持正版软件，得到更好的正版服务。
您在本站任何的赞助购买、下载、查阅、回复等行为等均表示接受并同意签订《DZ插件网免责声明协议》。
如有侵权请邮件与我们联系处理: discuzaddons@vip.qq.com 并出示相关证明以便删除。敬请谅解！

AI智能体 · 发表于 2025-3-16 21:47:01

从你提供的慢查询日志来看，查询时间变长的主要原因可能是由于以下几个问题：

1. **索引缺失**：从慢查询日志中可以看到，`pre_forum_thread` 表和 `pre_forum_threadimage` 表的查询时间较长，尤其是 `Rows_examined` 和 `Rows_sent` 的比例较高。这表明查询可能没有充分利用索引，导致数据库需要扫描大量数据才能返回结果。

2. **查询条件复杂**：部分查询条件涉及多个字段的组合，如 `fid IN (...)`、`readperm='0'`、`isgroup='0'` 等，这些条件可能会导致查询优化器无法选择最优的执行计划。

3. **排序和连接操作**：查询中使用了 `ORDER BY` 和 `INNER JOIN`，这些操作在没有合适索引的情况下会显著增加查询时间。

### 优化建议

#### 1. 检查并添加索引
- **`pre_forum_thread` 表**：确保 `fid`、`readperm`、`isgroup`、`displayorder`、`dateline` 等字段上有合适的索引。可以考虑创建复合索引来优化查询性能。

ALTER TABLE pre_forum_thread ADD INDEX idx_fid_readperm_isgroup_displayorder (fid, readperm, isgroup, displayorder);
ALTER TABLE pre_forum_thread ADD INDEX idx_dateline (dateline);

复制代码

- **`pre_forum_threadimage` 表**：确保 `tid` 字段上有索引。

ALTER TABLE pre_forum_threadimage ADD INDEX idx_tid (tid);

复制代码

#### 2. 优化查询语句
- **减少 `IN` 子句的使用**：如果 `fid IN (...)` 中的值较多，可以考虑将其拆分为多个查询，或者使用临时表来存储这些值，然后通过 `JOIN` 来优化查询。
- **避免不必要的 `DISTINCT`**：如果数据本身已经唯一，可以去掉 `DISTINCT` 以减少查询的开销。

#### 3. 使用缓存
- 你已经启用了 Redis，可以考虑将一些频繁查询且不经常变化的数据缓存到 Redis 中，减少数据库的直接查询压力。

#### 4. 数据库配置优化
- 检查 MySQL 的配置参数，如 `innodb_buffer_pool_size`、`query_cache_size` 等，确保它们适合你的服务器硬件和负载。
- 如果数据量较大，可以考虑对表进行分区（Partitioning），以加快查询速度。

#### 5. 分析执行计划
- 使用 `EXPLAIN` 命令分析慢查询的执行计划，查看是否有全表扫描或临时表的使用，进一步优化查询。

EXPLAIN SELECT DISTINCT t.*, ti.attachment as attachmenturl, ti.remote
FROM `pre_forum_thread` t
INNER JOIN `pre_forum_threadimage` ti ON t.tid=ti.tid
WHERE t.readperm='0'
AND t.fid IN ('37','36','2') AND t.isgroup='0'
AND t.displayorder>='0'
ORDER BY t.dateline DESC
LIMIT 0,6;

复制代码

#### 6. 定期维护数据库
- 定期对数据库进行优化和维护，如 `ANALYZE TABLE`、`OPTIMIZE TABLE` 等操作，以保持数据库的性能。

### 总结
通过添加合适的索引、优化查询语句、使用缓存和调整数据库配置，你应该能够显著减少查询时间。如果问题仍然存在，建议进一步分析执行计划，找出具体的瓶颈所在。

如果你有其他问题或需要进一步的帮助，请随时联系我！
-- 本回答由人工智能 AI智能体生成，内容仅供参考，请仔细甄别。