【问题标题】:Two queries vs one query, performance两个查询对一个查询,性能
【发布时间】:2009-05-13 19:53:55
【问题描述】:

在PHP+MySQL+PDO中,会不会慢很多

  • 按名称获取项目 ID
  • 按 ID 获取商品数据

不仅仅是

  • 按名称获取商品数据

后者只是一个查询,所以显然更快。前者使代码更简洁(因为项目的 ID 通常也是事先知道的),所以如果性能差异足够小会更好。

我正在使用的代码:

公共函数 actionView() {

    // read http request
    ...

    // get item
    $itemModel = new Rust_Model_Item();
    try {
        $id = $itemModel->getItemIdByUrlTitle($urltitle);
        $item = $itemModel->getItem($id); // lots of data
    } catch (Rust_Model_Item_NotFoundException $e) {
        throw new FastMVC_Web_Error(404, 'Item not found');
    }

    ...

}

http://code.heukelom.net/filedetails.php?repname=rust&path=%2Ftrunk%2Flib%2Fclasses%2FRust%2FController%2FItem.php

公共函数 getItem($id) {

    $item = $this->getItemBasics($id);

    $catModel = new Rust_Model_Category();
    $item['category'] = $catModel->getById($item['category_id']);

    $ratingModel = new Rust_Model_Rating();
    $item['rating'] = $ratingModel->getForItem($id);

    $pageModel = new Rust_Model_Page();
    $item['pages'] = $pageModel->getListForItem($id);

    $tagModel = new Rust_Model_Tag();
    $item['tags'] = $tagModel->getForItem($id);

    return $item;

}

http://code.heukelom.net/filedetails.php?repname=rust&path=%2Ftrunk%2Flib%2Fclasses%2FRust%2FModel%2FItem.php

【问题讨论】:

  • 不管“参考数据”如何,您都应该能够使用来自其他表和子查询的 JOINS 来组装所有信息。查找诸如 SELECT foo FROM bar WHERE foo IN(SELECT baz FROM boo) 之类的内容
  • 我很精通 SQL,这不是问题。并不是我不知道单个查询是什么,而是它会对我的设计产生负面影响。

标签: php mysql performance oop


【解决方案1】:

您应该设计您的查询,以便您在 WHERE 子句中使用的字段具有正确的键和索引设置,并且只使用一个查询来选择它们。

【讨论】:

    【解决方案2】:

    为什么不创建一个通过 id 获取项目数据的查询,在 id 上放置一个索引。

    【讨论】:

    • 虽然如果他也给名字加上索引,那么他可以根据情况选择使用哪一个。
    • 因为我将数据访问部分放在我的函数中的方式。我有一个非常大的函数,它通过 id 获取项目数据。不知何故,扩展该功能以使用名称(以及谁知道其他未来条件)也感觉不太干净。关于干净的代码,最好先选择id,然后选择数据。我只是担心性能。
    • 如果您从数据库中按需获取对象成员,请考虑使用某种形式的“使用 ID”来标识调用者(LINEFILE 可能会有所帮助)。执行每个成员的提取,但缓存他们使用的那些。这样,您可以在下次预加载它们并按访问获取由于控制流而出现的其他内容
    猜你喜欢
    • 2014-10-05
    • 2018-05-12
    • 1970-01-01
    • 2012-11-17
    • 1970-01-01
    • 2011-03-30
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多