谁能告诉我getItems()模型中的函数是否会在执行查询之前自动添加全局设置的 LIMIT（来自getListQuery()）。Joomla 真的很挣扎，似乎试图缓存整个结果（这里有超过 100 万条记录！）。
在查看/libraries/legacy/model/list.php和/libraries/legacy/model/legacy.php之后，似乎getItems()确实在将结果发送到缓存之前使用 setQuery 添加了 LIMIT$this->getState('list.limit')但如果是这种情况 - 为什么是Joomla 苦苦挣扎。
发生什么了？为什么 phpMyAdmin 可以在一秒钟内返回有限的结果而 Joomla 只是超时？
非常感谢！
如果您有 100 万条记录，您肯定会按照 Riccardo 的建议，覆盖和优化模型。
JModelList 运行查询两次，一次用于分页编号，然后用于显示查询本身。您需要小心地从JModellist继承以避免分页查询。
此外，articles 查询因其连接而臭名昭著。您肯定会失去一些减速（例如，怀疑您正在使用联系人链接）。
如果所有文章都对公众可见，您可以删除 ACL 检查- 这是相当昂贵的。
也没有来自西方或东方的 DBA 能够解释为什么需要所有这些GROUP BY。
失去这些东西会有很大帮助。事实上，从头开始构建查询可能是最好的。
它确实会自动添加分页。
它的挣扎很可能是由于大型数据集（即集合中返回的 1000 多个项目）和许多查找字段：例如内容模块连接多达 10 个表，以获取作者姓名等。
这可能是一个真正的杀手，我在专用服务器上运行了超过一秒钟的查询，并且只有 3000 个内容项。我们发现的一个标签云组件可能需要长达 45 秒才能返回一个关键字列表。如果是这种情况（很多记录和很多join），你唯一的出路就是进一步限制options中的filters，看看能不能得到一些更快的结果（比如限制最近3个月的文章可以大大减少所需的时间）。
但是，如果这还不够或不可行，您将不得不在新模型中编写新的优化查询，这最终将带来任何其他优化的最佳性能优化。在编写查询时，请考虑利用数据库特定的优化，即添加索引、全文索引，并且仅在您真正需要时才使用连接。
还要考虑连接决不能随着字段、翻译或其他的数量而增长。
数据库引擎很容易优化和缓存常量查询，而动态查询永远不会那么高效。