代码之家  ›  专栏  ›  技术社区  ›  flxh

MySql查询速度慢1000倍,限制稍高(不偏移)

  •  -1
  • flxh  · 技术社区  · 6 年前

    我有一个MySQL数据库,有大约12条IO记录。现在,我使用以下查询从该数据库中查询所需的行:

    SELECT date_time, price_l0, amount_l0, price_l1, amount_l1, price_l2, amount_l2, price_l3,  /* 34 more columns */
    FROM book_states
    WHERE date_time > ? and
          date_time < ? and
          bookID = ?
    ORDER BY date_time ASC
    LIMIT 4350
    

    上限约4340 此查询需要大约 4350 它需要 3.0/0.15秒

    如果我选择较少的列,那么非常快的查询和非常慢的查询之间的阈值会稍微高一些,但是如果限制在5000以上,即使我只选择一列,也需要3秒或更长的时间。

    现在我怀疑这是一个MySQL设置问题或某种RAM限制,但由于我不是MySQL专家,我要求您解释是什么导致了这个严重的性能问题。

    编辑: 这是一个需要3秒的查询的JSON解释数据

    {
      "query_block": {
        "select_id": 1,
        "cost_info": {
          "query_cost": "282333.60"
        },
        "ordering_operation": {
          "using_filesort": true,
          "table": {
            "table_name": "book_states",
            "access_type": "ref",
            "possible_keys": [
              "index1",
              "index2",
              "index3"
            ],
            "key": "index2",
            "used_key_parts": [
              "bookID"
            ],
            "key_length": "2",
            "ref": [
              "const"
            ],
            "rows_examined_per_scan": 235278,
            "rows_produced_per_join": 81679,
            "filtered": "34.72",
            "index_condition": "(`datastore`.`book_states`.`bookID` <=> 29)",
            "cost_info": {
              "read_cost": "235278.00",
              "eval_cost": "16335.84",
              "prefix_cost": "282333.60",
              "data_read_per_join": "14M"
            },
            "used_columns": [
              "id",
              "date_time",
              "bookID"
            ],
            "attached_condition": "((`datastore`.`book_states`.`date_time` > '2018-09-28T16:18:49') and (`datastore`.`book_states`.`date_time` < '2018-09-29T23:18:49'))"
          }
        }
      }
    }
    
    1 回复  |  直到 6 年前
        1
  •  4
  •   Gordon Linoff    6 年前

    查询的最佳索引位于: (bookID, date_time) . 注意列的顺序,这是非常重要的。

    MySQL正在努力用手头的索引优化查询。它可以使用 date_time 您提到的索引的一部分(或在 bookId)

    或者,它可以扫描你的复合索引(它有按日期/时间排序的记录),过滤掉不需要的书籍。

    在这两种方法中进行选择是你(大概)看到的。哪一个更好取决于收集到的统计数据,它们必然只提供部分信息。

    因此,切换索引中的列,问题应该会消失,至少对于这个特定的查询。