X3.4 forum_post 主鍵問題

cordless

專家 發表于 2023-2-16 23:09
你得先把position的auto increment去掉……

注意，去掉以后這張表就不能在3.4正常運行了，只在升級的時候 ...

我試了把數據從innodb 轉回 MyISAM發現tid這欄的基數變大了幾千,
position 的基數變成空值,如果再做上下次序對調,tid變成空的,position的基數是剛剛tid的基數.
這樣正常嗎?試了發帖都正常就是了.

專家

cordless 發表于 2023-2-17 17:27
我試了把數據從innodb 轉回 MyISAM發現tid這欄的基數變大了幾千,
position 的基數變成空值,如果再做上下 ...

auto increment去掉就不需要轉回myisam了啊……理論上可以直接對調索引里的tid和position了

之前使用對調過的tid和position肯定會產生不少錯誤數據，因此數據上有點異常應該問題不大，之后產生的數據就沒有問題了。

專家

stonys 發表于 2023-2-17 08:47
使用過3.4 的innodb方案。
Discuz! X2.5/X3-X3.4  InnoDB數據庫補丁 beta1.0.8 【2017.8.1更新】
https:/ ...

position的正確數值應該是當前樓層的樓層號，和pid相同的話就不對了。
系統無法根據position快速檢索樓層，就會回退到用pid計數的方式，降低性能。
但如果后續產生的數據沒有錯的話，后續的數據是不受影響的，還可以根據position快速檢索。

不過按理說老版本innodb方案不應該有這個問題啊……雖然我沒用過，但是我之前看過它的實現原理，不應該樓層號寫錯的。可能是你那邊配置出錯了？

stonys

專家 發表于 2023-2-17 17:35
position的正確數值應該是當前樓層的樓層號，和pid相同的話就不對了。
系統無法根據position快速檢索樓層 ...

有沒辦法重新更新一下positon樓層號?

專家

stonys 發表于 2023-2-17 22:32
有沒辦法重新更新一下positon樓層號?

這個不太好弄，因為有必要更新的post表，量往往很大，重寫難度高。
可以考慮自制一個腳本將總樓層數非常多的帖子的position重寫一下。對同一個tid，按pid從小到大依次從1開始給position就行了。

cordless

專家 發表于 2023-2-18 22:00
這個不太好弄，因為有必要更新的post表，量往往很大，重寫難度高。
可以考慮自制一個腳本將總樓層數非常 ...

我看了下,我大概錯誤的地方只有幾頁,是不是我升級完X3.5后我查出forum_post表
每一個tid相同的,將position改成1起頭按順序就可以,沒再牽涉到其他表對嗎?

cordless

專家 發表于 2023-2-18 22:00
這個不太好弄，因為有必要更新的post表，量往往很大，重寫難度高。
可以考慮自制一個腳本將總樓層數非常 ...

我還看到forum_thread 也有一個maxposition也要改.

stonys

專家 發表于 2023-2-18 22:00
這個不太好弄，因為有必要更新的post表，量往往很大，重寫難度高。
可以考慮自制一個腳本將總樓層數非常 ...

用百度了下。
1、重算生成postions表。

1. create table positions
   
2. select
   
3.   -- rownum  判斷  @pre_tid是否和當前的tid一樣 ，true:讓 @i+=1 false:重置@i
   
4.   (
   
5.     @i := case
   
6.       when @pre_tid = tid then @i + 1
   
7.       else 1
   
8.     end
   
9.   ) rownum,
   
10.   b.pid,b.tid,b.position,
    
11.   --  設置 @pre_tid等于上一個 tid
    
12.   (@pre_tid := tid)
    
13. from
    
14.   `pre_forum_post` as b,
    
15.   (
    
16.     SELECT
    
17.       @i := 0,
    
18.       @pre_tid := ''
    
19.   ) AS a
    
20. group by
    
21.   tid,dateline
    
22. order by
    
23.   tid,dateline;

復制代碼

2、更新post表的postion字段

1. update `pre_forum_post` a,
   
2. positions b
   
3. set
   
4.   a.position = b.rownum
   
5. where
   
6.   a.pid = b.pid

復制代碼

不知道有沒有問題。
處理后，似乎沒什么變化。論壇依然CPU占用較高。
由3.4升級3.5后，CPU占用高這個問題一直沒找到原因。

之前3.x的innodb方案非常好用，性能很高。

數碼達人

stonys 發表于 2023-2-17 08:47
使用過3.4 的innodb方案。
Discuz! X2.5/X3-X3.4  InnoDB數據庫補丁 beta1.0.8 【2017.8.1更新】
https:/ ...

我也用了InnoDB數據庫補丁，看來還不敢升級X3.5

stonys

數碼達人 發表于 2023-2-19 10:00
我也用了InnoDB數據庫補丁，看來還不敢升級X3.5

之前的innoDB性能非常高，
3.4時我的服務器CPU是1核，平時負載非常低，CPU30%以下，
升級到3.5后的負載超高，都在100%左右。
后面沒辦法又花錢將CPU加到2核，負載依然很高，平時CPU在50-70%，也經常CPU到100%報警。

不清楚是不是3.5的性能問題，一直沒找到原因。