*: Require GLOBAL IndexOption for creating Global Index

[mjonss]

What problem does this PR solve?

Issue Number: close #52994

Building upon #55259, which is the Parser change needed for this PR.

Problem Summary:
To not surprise our users and create MySQL incompatibilities, we should require explicit mentioning of 'GLOBAL' when creating a Global Unique Index.

This also makes it easier to allow non-unique indexes as well as unique indexes already containing all partitioning columns to be GLOBAL.

Currently ALTER TABLE t PARTITION BY ... would implicitly create a Global Index of UNIQUE Indexes if they don't include all partitioning columns.
With this PR we are adding an optional UPDATE INDEXES clause after the partitioning definitions:
UPDATE INDEXES ( index_name {GLOBAL|LOCAL} [, index_name {GLOBAL|LOCAL}[,...]] ) to make every index change explicit.

What changed and how does it work?

DDL:

• Checking and propagating the options from the parser, so that we require GLOBAL to be explicitly mentioned when creating a global index.

Executor:

• Including /*T![global_index] GLOBAL */ as IndexOption in SHOW CREATE TABLE

Table:

• Just updated test to use GLOBAL IndexOption.

Added a new error for needing Global Index, but is not explicitly given.
Most changes are just updated tests and results, to comply with the new requirement of explicitly mention GLOBAL.

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No need to test

  • I checked and no code files have been changed.

Side effects

• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Breaking backward compatibility

Documentation

• Affects user behaviors
• Contains syntax changes
• Contains variable changes
• Contains experimental features
• Changes MySQL compatibility

Release note

Please refer to Release Notes Language Style Guide to write a quality release note.

Require GLOBAL IndexOption for creating a Global Index (experimental).

[tiprow]

Hi @mjonss. Thanks for your PR.

PRs from untrusted users cannot be marked as trusted with /ok-to-test in this repo meaning untrusted PR authors can never trigger tests themselves. Collaborators can still trigger tests on the PR using /test all.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[codecov]

Codecov Report

Attention: Patch coverage is 79.84496% with 26 lines in your changes missing coverage. Please review.

Project coverage is 75.6112%. Comparing base (876268f) to head (24d3ec5).
Report is 18 commits behind head on master.

Additional details and impacted files

@@               Coverage Diff                @@
##             master     #55264        +/-   ##
================================================
+ Coverage   74.7860%   75.6112%   +0.8251%     
================================================
  Files          1570       1580        +10     
  Lines        364854     449034     +84180     
================================================
+ Hits         272860     339520     +66660     
- Misses        72285      88722     +16437     
- Partials      19709      20792      +1083     

Flag	Coverage Δ
integration	50.1754% <75.1938%> (?)
unit	71.9732% <72.8682%> (-1.7505%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
dumpling	52.9567% <ø> (-2.2327%)	⬇️
parser	∅ <ø> (∅)
br	63.1826% <ø> (+15.5121%)	⬆️

[mjonss]

/retest

[tiprow]

@mjonss: Cannot trigger testing until a trusted user reviews the PR and leaves an /ok-to-test message.

In response to this:

/retest

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[mjonss]

/retest

[tiprow]

@mjonss: Cannot trigger testing until a trusted user reviews the PR and leaves an /ok-to-test message.

In response to this:

/retest

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[Defined2014]

Should we check is commonHandle here?

[mjonss]

Not sure, it is checked in the next loop over tbInfo.Indices, and will fail if CommonIndex and global index is needed for the same index.

[qw4990]

LGTM for the optimizer part

[ti-chi-bot]

[LGTM Timeline notifier]

Timeline:

• 2024-08-12 07:08:13.960062615 +0000 UTC m=+165378.663532243: ☑️ agreed by Defined2014.
• 2024-08-12 08:19:12.455645015 +0000 UTC m=+169637.159114675: ☑️ agreed by qw4990.

[mjonss]

/retest

[tiprow]

@mjonss: Cannot trigger testing until a trusted user reviews the PR and leaves an /ok-to-test message.

In response to this:

/retest

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Defined2014, qw4990, tangenta

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [Defined2014,qw4990,tangenta]
• pkg/ddl/OWNERS [tangenta]
• pkg/statistics/OWNERS [qw4990]
• pkg/table/OWNERS [tangenta]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[hawkingrei]

/retest