Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-6735

Range checked for each record used with key

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 5.5.39, 10.0.13
    • Fix Version/s: 10.0.20, 5.5.44
    • Component/s: Optimizer
    • Labels:
    • Sprint:
      10.0.20

      Description

      Using the attached mysqldump, the following query is very slow in MariaDB compared to MySQL 5.5 or MySQL 5.6:

      SELECT 1 FROM `catalog_category_flat_store_1` AS `main_table`
                    LEFT JOIN `core_url_rewrite` AS `url_rewrite`
                       ON url_rewrite.category_id=main_table.entity_id
                       AND url_rewrite.is_system=1
                       AND url_rewrite.store_id = 1
                       AND url_rewrite.id_path LIKE 'category/%'
                WHERE (main_table.include_in_menu = '1')
                AND (main_table.is_active = '1')
                AND (main_table.path like '1/2/%')
                ORDER BY `main_table`.`position` ASC
      

      The schema and query are part of Magento, but the attached dump has had FK, some unique indexes, and most of the columns dropped.

      The query plan in MySQL, which executes quickly:

      |  1 | SIMPLE      | main_table  | ALL   | IDX_CATALOG_CATEGORY_FLAT_STORE_1_PATH                                                                                                                       | NULL                                            | NULL    | NULL |  124 | Using where; Using temporary; Using filesort |
      |  1 | SIMPLE      | url_rewrite | range | UNQ_CORE_URL_REWRITE_ID_PATH_IS_SYSTEM_STORE_ID,IDX_CORE_URL_REWRITE_ID_PATH,IDX_CORE_URL_REWRITE_STORE_ID,FK_CORE_URL_REWRITE_CTGR_ID_CAT_CTGR_ENTT_ENTT_ID | UNQ_CORE_URL_REWRITE_ID_PATH_IS_SYSTEM_STORE_ID | 773     | NULL | 1138 | Using where                                  |
      

      5.6 has BNL and using Join buffer for the second table, and runs at a similar speed.

      In MariaDB 5.5 and MariaDB 10, the following slow plan is used:

      |    1 | SIMPLE      | main_table  | ALL   | IDX_CATALOG_CATEGORY_FLAT_STORE_1_PATH                                                                                                                       | NULL                                            | NULL    | NULL |  149 | Using where; Using filesort                     |
      |    1 | SIMPLE      | url_rewrite | range | UNQ_CORE_URL_REWRITE_ID_PATH_IS_SYSTEM_STORE_ID,IDX_CORE_URL_REWRITE_ID_PATH,IDX_CORE_URL_REWRITE_STORE_ID,FK_CORE_URL_REWRITE_CTGR_ID_CAT_CTGR_ENTT_ENTT_ID | UNQ_CORE_URL_REWRITE_ID_PATH_IS_SYSTEM_STORE_ID | 773     | NULL | 1138 | Range checked for each record (index map: 0x74) |
      

      This can be made fast in MariaDB with ADD INDEX ix_foo (category_id, store_id) or IGNORE INDEX.

      There also seems to be no optimizer_switch to turn off this strategy.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

              Hide
              mg MG added a comment -

              With this patch on 5.5.42, I have gotten a few different plans depending on what table statistics happen to be, each not using "Range checked for each record (index map: 0x1E)" and several orders of magnitude faster than unpatched 5.5.42 which uses "Range checked for each record (index map: 0x1E)" for my sample data and query.

              Show
              mg MG added a comment - With this patch on 5.5.42, I have gotten a few different plans depending on what table statistics happen to be, each not using "Range checked for each record (index map: 0x1E)" and several orders of magnitude faster than unpatched 5.5.42 which uses "Range checked for each record (index map: 0x1E)" for my sample data and query.
              Hide
              danblack Daniel Black added a comment -

              Sergei Petrunia , really keen to see your patch committed. While I'm still not sure why what "sel->quick->read_time" and "tab->table->file->scan_time()" are exactly (happy to remain ignorant for a while - I trust you), it does look better than rather arbitrary looking 100 row limit. While its always tough doing these changes for fear of regressions this is already a regression from 5.5.33. Magento has a not insignificant user base who would notice the difference between a 0.13 sec query and a 10 minute query once they reached a not too high limit on categories.

              Show
              danblack Daniel Black added a comment - Sergei Petrunia , really keen to see your patch committed. While I'm still not sure why what "sel->quick->read_time" and "tab->table->file->scan_time()" are exactly (happy to remain ignorant for a while - I trust you), it does look better than rather arbitrary looking 100 row limit. While its always tough doing these changes for fear of regressions this is already a regression from 5.5.33. Magento has a not insignificant user base who would notice the difference between a 0.13 sec query and a 10 minute query once they reached a not too high limit on categories.
              Hide
              danblack Daniel Black added a comment -

              can we get this patch into the next 5.5/10.0 release?

              Show
              danblack Daniel Black added a comment - can we get this patch into the next 5.5/10.0 release?
              Hide
              psergey Sergei Petrunia added a comment -

              Fix was pushed into 5.5 tree.

              Show
              psergey Sergei Petrunia added a comment - Fix was pushed into 5.5 tree.
              Hide
              psergey Sergei Petrunia added a comment -

              Daniel Black, thanks for all the input on the issue, also for your patience when waiting for it to be pushed!

              Show
              psergey Sergei Petrunia added a comment - Daniel Black , thanks for all the input on the issue, also for your patience when waiting for it to be pushed!

                People

                • Assignee:
                  psergey Sergei Petrunia
                  Reporter:
                  mg MG
                • Votes:
                  1 Vote for this issue
                  Watchers:
                  8 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved:

                    Agile