哈哈 这么python的写法 也支持了？

同意你的看法，至于效率问题，这个还真不好说，感觉差别不大

@zcx147716565 可以根据搜索先取ID，然后根据分页取全部结果，一次性取全部内容，消耗都在io上了，肯定慢。

@sk811229 哈哈 原来是这样

100万而已 如果增量不是特别大的话 同时你这俩字段是char、varchar和text类型的话，可以试试mysql原生的fulltext索引，无附加组件，少量修改代码就可完成模糊搜索。如果增量很大，频率很高，可以尝试第三方组件，比如es、sphinx之类。我个人经验告诉我，如非特别必要，尽量保持技术栈的简单，不然就是运维地狱。

1.视图中无法打印当前页面form将要提交的数据格式吧？
2.你可以试试在控制器中打印Yii::$app->request->post();
3.$model->keyword中的$model是啥？form模型还是ar模型？如果是form模型那需要看看你view中的代码了，如果是ar模型，那需要你先赋值或者有个$model->load(Yii::$app->request->post())这种类似的操作才行吧

总体感觉你的提问的信息量不足以精确定位错误，需要你进一步排查了

我个人理解 模型实例化后就是一组数据，和一些处理这些数据的方法，无论是来自数据库还是用户输入都可以抽象成这种概念，控制器呢 只是负责逻辑，也就是要把那些数据交给哪些模型的哪些方法来处理。这种方式可以少理解很多概念，同时也可以尽量做到复用性强一些，这种处理方式也有劣势，就是很多时候造成数据处理过于碎片化，简单工作需要太多地方协同。在实际应用过程中，yii给我们的自由度很高，个人项目主要依照个人习惯就好，公司项目那就小团队约定就好，不必拘泥太多形式。

请记住一句话：永远不要对浮点数做大小比较运算！
所以，不管哪个PHP框架,甚至哪种编程语言，mysql也不例外，对浮点数的比较操作都有这种问题，这都是其计算机底层对浮点数的实现：IEEE754
所以，一通百通，不要怪yii2框架，也不要怪php。这个标准有利有弊，自己见多了就识广了。

@xiaopig 我没用过3台同时消费，目前用到的是2台，运行还算稳定。yii不活跃估计是队列用的人不多导致的，毕竟yii-queue是个比较弱的队列，我们也在打算更换到更健壮交互更详细的一些队列

这个需要说下具体情况，你这么直接说，我感觉是能够消费的