您有很多问题要解决-而call_user_func_array不是其中之一.

看看你的查询

这是您要构建的查询：

SELECT

*

FROM

trabajosEnSubasta

WHERE

MATCH(titulo, descripcion, habilidades) AGAINST (?)

UNION

SELECT

*

FROM

trabajosEnSubasta

WHERE

MATCH(titulo, descripcion, habilidades) AGAINST (?)

UNION

SELECT

...

并且..这就引出了一个问题,为什么你会那样做.这在功能上是相同的,并且执行起来可能快得多：

SELECT

*

FROM

trabajosEnSubasta

WHERE

MATCH(titulo, descripcion, habilidades) AGAINST (?)

OR

MATCH(titulo, descripcion, habilidades) AGAINST (?)

OR

...

看你的逻辑

$paramsArr = explode(",", $_GET['paramsQuery']);

因此,请求类似/ foo？paramsQuery = a,b,c,d,e,f,g,h,i,j的url当前会触发10个表的联合查询,如果您更新查询语法,那将是一个10.全文索引查询.那真的是你想要的吗？可能是-但是例如,如果有人搜索已知的哈比利达德,这样做的效率会更高：

SELECT

trabajosEnSubasta.*

FROM

trabajosEnSubasta

LEFT JOIN

habilidades_map ON habilidades_map.trabajo_id = trabajosEnSubasta.id

WHERE

habilidades_map.habilidad = "known habilidad"

全文索引的查询成本相对较高,因此,它实际上并不是您搜索数据的唯一方法.

分析您的代码

我必须假设您正在询问call_user_func_array,因为您的代码执行速度很慢.不要猜测代码查找和发现问题的地方.

>使用explain查看您的查询正在做什么

>使用xdebug profiling查看代码花费的时间

> Webgrind是查看xdebug配置文件输出的一种易于安装的方式.

不要浪费时间优化0.01％

call_user_func_array确实有使用成本,这就是为什么code like this存在的原因.但是区别实际上是非常微小的(尤其是考虑到问题中超重的UNION查询),除非您多次调用它.专注于对应用程序性能影响最大的事物,而不是一种或两种方式完全没有可测量差异的事物.