mysql join 查询在露天很慢，但使用索引

Question

我们在使用 Alfresco 4.0.e 和 mysql 5.5 后端时遇到了一些性能问题。

通过性能监视器，我可以看到很多请求(不确定是什么触发了这些)在数据库上挂起，响应时间接近 100-200 秒。极端情况下为 3000 秒。

所有这些请求都源自本地的 alfresco 应用程序(不共享我们在单独服务器上的 gui)。客户端IP显示127.0.0.1。URL =/alfresco/service/api/solr/元数据进一步深入，似乎有 2 个查询，每个查询都需要 100 秒以上，如下所示 -

select
        assoc.id                    as id,
        parentNode.id               as parentNodeId,
        parentNode.version          as parentNodeVersion,
        parentStore.protocol        as parentNodeProtocol,
        parentStore.identifier      as parentNodeIdentifier,
        parentNode.uuid             as parentNodeUuid,
        childNode.id                as childNodeId,
        childNode.version           as childNodeVersion,
        childStore.protocol         as childNodeProtocol,
        childStore.identifier       as childNodeIdentifier,
        childNode.uuid              as childNodeUuid,
        assoc.type_qname_id         as type_qname_id,
        assoc.child_node_name_crc   as child_node_name_crc,
        assoc.child_node_name       as child_node_name,
        assoc.qname_ns_id           as qname_ns_id,
        assoc.qname_localname       as qname_localname,
        assoc.is_primary            as is_primary,
        assoc.assoc_index           as assoc_index
    from
        alf_child_assoc assoc
        join alf_node parentNode on (parentNode.id = assoc.parent_node_id)
        join alf_store parentStore on (parentStore.id = parentNode.store_id)
        join alf_node childNode on (childNode.id = assoc.child_node_id)
        join alf_store childStore on (childStore.id = childNode.store_id)

    where
        parentNode.id = ?

对此查询运行一个解释计划，其参数值似乎造成了最大的破坏(~3000秒)，这就是我所看到的-

    select_type table       type    possible_keys                       key               key_len   ref                       rows  Extra
    SIMPLE      parentNode  const   PRIMARY,store_id,fk_alf_node_store  PRIMARY           8         const                     1 
    SIMPLE      parentStore const   PRIMARY                             PRIMARY           8         const                     1 
    SIMPLE      childStore  index   PRIMARY                             protocol          454       NULL                      6     Using index
    SIMPLE      childNode   ref     PRIMARY,store_id,fk_alf_node_store  store_id          8         alfrescomgr.childStore.id 162579    
    SIMPLE      assoc       ref     parent_node_id,fk_alf_cass_pnode,   fk_alf_cass_cnode 8         alfrescomgr.childNode.id  1     Using where
                                    fk_alf_cass_cnode  

注意行数 = 162k。对于几个这样的查询，父节点似乎指向一个存储数千个小型报价文档的文件夹。

我们的应用程序推送文档并通过一些元数据属性(例如客户 ID)查询它们。我们使用 apache Chemistry cmis api 进行交互。

1. 您认为是什么触发了 solr 查询。它试图加载所有子节点上的信息。
2. 如果我们无法控制solr部分，我们如何优化它。

非常感谢您的帮助。

Answer 1

不久前，我在 Solaris 上的 4.0.d 实例(带有 MySQL)上遇到了类似的性能问题，结果发现我的 MySQL 版本的默认引擎性能很差!

一旦我对 join/where 子句中引用的每一列建立索引，问题就消失了，并且我获得了 98% 以上的性能提升!