ink 發(fā)表于 2022-5-12 10:42
謝謝推薦，這類插件我看過，可惜我的站點(diǎn)暫時(shí)還是GBK的，另外可能馬上面臨3.5的升級，暫時(shí)還是緩一緩。 ...

用排除法即可:
把你的查詢時(shí)間很久的那句復(fù)制到mysqladmin自定義執(zhí)行命令里面去手動查看, 看看要多久,

然后依次該句的條件項(xiàng), 看是哪一個(gè)條件引起的耗時(shí)

天外飄仙 發(fā)表于 2022-5-12 08:54
可以試試 我開發(fā)的xunsearch搜索插件: https://addon.dismall.com/plugins/twpx_xunsearch.html
搜索速度和 ...

謝謝推薦，這類插件我看過，可惜我的站點(diǎn)暫時(shí)還是GBK的，另外可能馬上面臨3.5的升級，暫時(shí)還是緩一緩。

可以試試 我開發(fā)的xunsearch搜索插件: https://addon.dismall.com/plugins/twpx_xunsearch.html
搜索速度和效果 要比   dz自帶的好 不少——而且全文搜索 也不會對 數(shù)據(jù)庫造成壓力

dashen 發(fā)表于 2022-5-8 19:42
不像自帶的sql

我曾經(jīng)也懷疑過，所以剛才去后臺設(shè)置內(nèi)把搜索的最大搜索結(jié)果改成了400，過了一會再去看慢日志：

\n# Time: 2022-05-10T04:10:13.815770Z\n# User@Host: *** @ localhost [127.0.0.1]  Id: 8774685\n# Query_time: 3.068823  Lock_time: 0.000116 Rows_sent: 43  Rows_examined: 1817067\nSET timestamp=1652155813;\nSELECT  t.tid, t.closed, t.author, t.authorid FROM forum_thread t WHERE  t.fid IN ('176','183','166','147','174','31','56','77','78','80','76','158','160','167','171','178','179','240','241','247','248','249','262','282','156','74','70','71','72','73','69','97','161','86','136','169','173','175','92','94','182','281','159','285','88','89','90','48','25','21') AND t.displayorder>='0' AND (0 OR t.subject LIKE '%s905x3%') ORDER BY tid DESC LIMIT 400;

還真得就是系統(tǒng)自帶的搜索。

不像自帶的sql

搜索本身就挺費(fèi)的，可以試試換成innodb，限制搜索時(shí)間，或者使用插件https://addon.dismall.com/plugins/xunsearch.html

耗子 發(fā)表于 2022-5-8 13:15
會不會和插件有關(guān)系，    分表下試試

而且主題表不敢分表啊，后患無窮

以前進(jìn)行過用戶表優(yōu)化，后悔不已，有陰影了……

mingkong 發(fā)表于 2022-5-8 12:41
看起來不是很像系統(tǒng)自帶的查詢語句，可以請人改進(jìn)這個(gè)慢查詢的查詢方法。 ...

應(yīng)該就是這個(gè)搜索界面：http://r615.cn/search.php?mod=forum&adv=yes