Manage index hinting for sharding data iterator query

[mtaner]

Recently we have discovered that USE INDEX can slow the data iterator batching queries down as MySQL can decide to do a table scan instead, where as not using it allows the optimizer to select the correct index & avoid table scan. FORCE INDEX prevents MySQL from doing a table scan also but it removes the flexibility of selecting another index for the sharding key that might be more suitable. Another theory is that query optimizer is better in MySQL 8 and therefore we might not need to use "USE INDEX" to ensure MySQL is using the correct index with this version (index hinting was originally introduced for optimizer selecting the wrong index with 5.7 for some tables.)

This is why I am introducing a configuration to manage the index hinting for the sharded data iterator.

IndexHint // "use" by default. Options "none", "use", "force"

IndexHintingPerTable // has higher specificity then higher level IndexHint if specified

example:
IndexHintingPerTable: { 
   "blog": { // schema name
      "users": { // table name
	 "IndexHint": "force" // has higher level specificity then higher level IndexHint
	 "IndexName": "ix_users_some_id" // defaults to empty string, will override the index chosen by Ghostferry
	},
      "accounts": {
          "IndexName": "ix_accounts_some_id" // indexName will be ignored if it doesn't exist on the table
          // will inherit the higher level IndexHint as not specified
     }
 }

[mtaner]

by this point, the validation should have caught "invalid" IndexHint options but for some reason it doesn't we always default to the existing behaviour with "USE INDEX"

[yongli-shopify]

I suggested to convert indexHint to lowercase before comparing, so it provides good flexibility for input, like use, Use, USE, ForCe .etc., which will be super convenient and less error-prone and easy to maintain

[mtaner]

already doing here: https://github.com/Shopify/ghostferry/pull/380/files#diff-98e32b41746dfde3eae5ea7e3ececaa8db1cfcbcc4889e9d4634ebb0c7aa2782R100

[yongli-shopify]

I think it should be IndexHintingPerTable here?

Suggested change

	IndexConfigPerTable: config.ShardedCopyFilterConfig.IndexConfigForTables(config.SourceDB),
	IndexConfigPerTable: config.ShardedCopyFilterConfig. IndexHintingPerTable(config.SourceDB),

[mtaner]

This is a method I created on ShardedCopyFilterConfig, so it is correct

[yongli-shopify]

So by default this is not configured? then where will this be configured?
And I didn't see there are unit tests for ShardedCopyFilterConfig?

[mtaner]

It can be not specified yes - we need to make sure we are backwards compatible. I didn't have to add unit tests before I was only generating an empty hash if it didn't exists but now I am specifically checking for "IndexHint" values so there is a test for this config validation.

[ilikeorangutans]

Happily surprised to see Squirrel here.