前段時間，利用centos7 + nginx + php8 + mysql8 部署了一個nextcloud，首選的是當時最新穩定版的NC22，根據官方文檔一步步操作下來，遇到了很多問題
部署完成后，NC首次登錄不上的、登錄上去，無限循環 /remote.php/dav的，還有一個樣式混亂的（重啟web服務就好了，也不知道為什么）。
后面換了NC21版本，就沒這些問題了。。。。。
部署完成之后，開始改代碼，支持單點登錄。不得不說，nextcloud的代碼真不錯，耦合性不強。
登錄驗證是通過 OC\Authentication\Login\Chain 構建的鏈條一步步驗證下去的
（真不錯，這代碼，單點登錄的驗證也就是加在這鏈條上）
改完單點登錄，又發現了新的問題。上傳速度慢，最終的解決方法是，把PHP，nginx上傳的參數配置調大，同時，不限制nextcloud文件分塊大小。
后面通過掛載，掃描添加了幾百上千萬的文件，這時候，又出現了一個問題。。。
就是mysql的CPU占用很高（一直）。說說我處理的過程：
一開始，我以為是sql語句執行慢，導致的，跑去看了慢日志，結果沒什么發現，后面又將fpm的日志，nginx的錯誤日志都看了，一樣沒什么發現。
通過SHOW FULL PROCESSLIST看到有幾個線程執行一樣的SQL語句，執行時間很長，一直都是executing的狀態。但不知道是在哪觸發的。
索性，我把nginx關閉，php-fpm關閉，但是MySQL的cpu負載還是下不來。這時候，可以想到應該是定時任務觸發的SQL語句了。
后面通過nextcloud社區了解到，很多人都出現這個問題和文件掃描的定時任務每隔12個小時就會執行一次。在SHOW FULL PROCESSLIST中的Time可以驗證這一點，說明是從文件掃描的定時任務觸發的SQL查詢。
想要解決這個問題，可以直接關閉文件掃描的后台任務，如果是通過web上傳的文件，一般不會觸發文件掃描的，我是通過掛載，而且掛載文件很多，文件和文件夾的大小都沒有進行統計，才會觸發的。
這里放一下SQL語句 （順便提一下：oc_filecache的數據量在1300w左右，oc_mounts的數據量在500左右）
SELECT MAX(`user_id`) FROM `oc_filecache` `f` INNER JOIN `oc_mounts` `m` ON `storage_id` = `storage` WHERE `size` < 0 GROUP BY `storage_id` LIMIT 500; SELECT `path` FROM `oc_filecache` WHERE (`storage` = 18 ) AND (`size` < 0 ) ORDER BY `fileid` DESC LIMIT 1;
一共發現兩條SQL語句會出現這樣的問題。通過分析，發現 這兩條語句執行時索引都沒有用對（stroage,size 和 size都是有索引的）。這兩條SQL語句可以執行很久很久。。。。。
一開始我還以為是產生了死鎖，但是不是，其實就是一直在執行，沒有盡頭。
我還用strace -p 分析了php定時任務的進程，就一直在restart_syscall，應該是在等待SQL返回數據。
后面看了oc_filecache的數據發現，size < 0的情況就只有 size = -1 （等於查詢肯定比范圍查詢要好啊），所以最后就把size < 0 改成了size = -1了。雖然sql查詢還有有點慢，但至少能結束，返回數據，總比之前沒有返回的執行好。
但是如果，size < 0 的情況有很多種，那就不適用了。。。。
按照上面的處理后，MySQL的負載就下來了，也沒有定時任務一直在等待返回了。
如果有人知道關於nextcloud的其它問題和解決辦法，請告訴我，不勝感激（因為后面還要對它進行二開）
算是告一段落吧。。。