Amursky1988

Решение найдено! После многих тестов, смен БД я наконец то нашел причину долгого поиска. Проблема была действительно в БД., а точнее напишу чуть ниже. Включив логирование медленных запросов SET GLOBAL slow_query_log=1; я отследил какой запрос формируется через веб поиск

SELECT `filecache`.`fileid`, `storage`, `path`, `path_hash`, `filecache`.`parent`, `name`, `mimetype`, `mimepart`, `size`, `mtime`, `storage_mtime`, `encrypted`, `etag`, `permissions`, `checksum`, `metadata_etag`, `creation_time`, `upload_time` FROM `oc_filecache` `filecache` LEFT JOIN `oc_filecache_extended` `fe` ON `filecache`.`fileid` = `fe`.`fileid` WHERE (`storage` = 2) AND (`name`  COLLATE utf8mb4_general_ci LIKE '%namefile%');

выполнив этот запрос непосредственно в консоли mysql я убедился, что запрос также выполняется около минуты, это сразу сняло подозрения на всевозможные домыслы в сторону проблем веб интерфейса, ранее когда я писал что через консоль бд я делал запрос и он выполнялся за доли секунды, то я оформил абсолютно не верный запрос, не такой какой формируется самой системой через веб поиск, это и сбило меня столку.
немного погуглив я познакомился с параметром

mysql> SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
+-------------------------+-----------+
| Variable_name           | Value     |
+-------------------------+-----------+
| innodb_buffer_pool_size | 134217728 |
+-------------------------+-----------+
1 row in set (0.01 sec)

mysql>

он дает представление от том какой размер памяти выделяется для хранения данных и индексов таблиц. 134217728 это значение равное 128 Мб. Логично предположить для того чтобы выделить достаточное кол-во памяти для хранения данных и индексов таблиц надо знать сколько эти данные занимают места, для этого выполним команду

mysql> SELECT table_schema "nextcloud",
    -> Round(Sum(data_length + index_length) / 1024 / 1024, 1) "DB Size in MB"
    -> FROM   information_schema.tables
    -> GROUP  BY table_schema;
+--------------------+---------------+
| nextcloud          | DB Size in MB |
+--------------------+---------------+
| information_schema |           0.2 |
| mysql              |           0.8 |
| nextcloud          |         415.6 |
| performance_schema |           0.0 |
| sys                |           0.0 |
+--------------------+---------------+
5 rows in set (0.13 sec)

Где видно что уже занято 415 Мб, соответственно нам надо задать параметр innodb_buffer_pool_size более того что занимает у нас БД, к примеру дадим 1 Гб

mysql> SET GLOBAL innodb_buffer_pool_size=1073741824;
Query OK, 0 rows affected (0.00 sec)

Проверим изменился ли параметр

mysql> SELECT @@innodb_buffer_pool_size;
+---------------------------+
| @@innodb_buffer_pool_size |
+---------------------------+
|                1073741824 |
+---------------------------+
1 row in set (0.00 sec)

Теперь идем в веб интерфейс и обновляем страницу и проверяем поиск. И конечно убеждаемся что все ищется очень быстро.
Все конечно хорошо , но после перезагрузки сервера наши изменения по параметру innodb_buffer_pool_size не сохранятся так как в snap версии не редактируется конфигурационный файл БД

/snap/nextcloud/current/my.cnf  вот этот файл и он только для чтения

Как его поправить я пока не знаю, пишите если знаете.

PS. chmod не рабоатет. Я так понимаю nextcloud монтирует какой то раздел вместе с этим фалом только для чтения.