前段时间，利用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的其它问题和解决办法，请告诉我，不胜感激（因为后面还要对它进行二开）
算是告一段落吧。。。