Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Index hints #9421

Open
sushantdhiman opened this issue May 9, 2018 · 13 comments

Comments

10 participants
@jessethomson

This comment has been minimized.

Copy link

commented May 17, 2018

Okay, I think a good starting point might be to go over SQL capabilities, and how/if we want to implement all of these.

Valid MySQL queries:

  1. SELECT * FROM t1 USE INDEX (); Without using indices
  2. SELECT * FROM t1 USE INDEX (i1); With single index
  3. SELECT * FROM t1 USE INDEX (i1,i2); With multiple indices
  4. SELECT * FROM t1 USE INDEX (i1) USE INDEX (i2); With multiple USE INDEX

I think 1, 2, and 3 are all reasonable functionality. I don't see any reason why we would need to implement 4. As far as I know, 4 is simply a syntactically different way to represent 3, without adding any new functionality (I could be wrong).

Note: It is perfectly valid to use the same index more than once in an index hint.
For example:
SELECT * FROM t1 USE INDEX (i1) USE INDEX (i1);
and
SELECT * FROM t1 USE INDEX (i1,i1);
are both valid statement so we don't need to enforce index uniqueness.

@jessethomson

This comment has been minimized.

Copy link

commented May 17, 2018

Also, it looks like all 3 Pull Requests referenced in the original post are for MySQL. I don't think there is any actual demand for this feature outside of the MySQL dialect; at least nothing that I have been able to find online.

@henryarbolaez

This comment has been minimized.

Copy link

commented May 17, 2018

Agree with you @jwt1143 on my PR I was able to pass a collection of indexes. I like option 1, 2 and 3 aswell

SELECT * FROM Order USE INDEX(idx_status_id) WHERE status_id = 1

@henryarbolaez

This comment has been minimized.

Copy link

commented May 17, 2018

Also, I like to support the ability to use FORCE INDEX sometimes is useful but rare.

@ezequielzacca

This comment has been minimized.

Copy link

commented May 18, 2018

is not rare at all for very large databases

@jessethomson

This comment has been minimized.

Copy link

commented May 18, 2018

Okay. I think it makes sense to support force (and probably ignore too in that case).

Here's an API proposal:

We add an indexHints property to the sequelize options.

db.User.findOne({
    where: {
        email: "joe@example.com",
    },
    indexHints: [
        { type: "use", values: ["i1"] }
    ],
});

Examples:

SELECT * FROM t1 USE INDEX ();

indexHints: [
    { type: "use", values: [] },
]

SELECT * FROM t1 USE INDEX (i1);

indexHints: [
    { type: "use", values: ["i1"] },
]

SELECT * FROM t1 USE INDEX (i1,i2);

indexHints: [
    { type: "use", values: ["i1", "i2"] },
]

SELECT * FROM t1 FORCE INDEX (i1);

indexHints: [
    { type: "force", values: ["i1"] },
]

SELECT * FROM t1 IGNORE INDEX (i1);

indexHints: [
    { type: "force", values: ["i1"] },
]

SELECT * FROM t1 USE INDEX (i1,i2) IGNORE INDEX (i2);

indexHints: [
    { type: "use", values: ["i1","i2"] },
    { type: "ignore", values: ["i2"] },
]

Notes

I prefer using objects over arrays to represent each index hint because they are more explicit.
For example:

indexHints:[
    ["use", ["i1","i2"]]
]

is not nearly as clear as

indexHints: [
    { type: "use", values: ["i1","i2"] },
]

Being more verbose shouldn't be an issue as indexHints are only used in limited/rare circumstances.

@sushantdhiman

This comment has been minimized.

Copy link
Member Author

commented May 23, 2018

@jwt1143 Your proposal looks good, some comments

type should be an constant like query hints

indexHints: [
    { type: IndexHints.USE || FORCE || IGNORE, values: ["i1","i2"] },
]

I also do perfer object based approach

indexHints: [
    { type: IndexHints.USE, values: ["i1","i2"] },
]

As for implementation

MSSQL

We are only going to introduce this

WITH (TableHints, INDEX (<index>))

Form of table hint expansion, we already support table hints for MSSQL, we just need to include index part when indexHints is also supplied, see this pull request

SQLite

Only need to add

INDEXED BY <index_name>

For any given indexHints

MySQL

Up to you, as that is your primary objective with this issue

@monukanyal

This comment was marked as off-topic.

Copy link

commented Oct 5, 2018

Any update?

@OsoianMarcel

This comment was marked as off-topic.

Copy link

commented Nov 5, 2018

+

@peteychuk

This comment was marked as off-topic.

Copy link

commented Dec 12, 2018

+1

1 similar comment
@danfarewell

This comment was marked as off-topic.

Copy link

commented Dec 19, 2018

+1

@KevinTemes

This comment was marked as off-topic.

Copy link

commented Mar 18, 2019

+1. Any updates on this? Im currently having some index-related issues on MSSQL and a feature like this would be really helpful.

@Diferno

This comment was marked as off-topic.

Copy link

commented Apr 2, 2019

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.