engine, if you specify a non-zero value for the
KEY_BLOCK_SIZE table option for the whole table, then the table will
implicitly be created with the ROW_FORMAT table option set to COMPRESSED.
However, this does not happen if you just set the KEY_BLOCK_SIZE index option
for one or more indexes in the table. The InnoDB storage engine ignores the
KEY_BLOCK_SIZE index option. However, the SHOW CREATE TABLE statement may
still report it for the index.

For information about the KEY_BLOCK_SIZE index option, see the KEY_BLOCK_SIZE
table option below.

Index Types
-----------

Each storage engine supports some or all index types. See Storage Engine Index
Types for details on permitted index types for each storage engine.

Different index types are optimized for different kind of operations:

* BTREE is the default type, and normally is the best choice. It is supported
by all storage engines. It can be used to compare a column's value with a
value using the =, >, >=, <, <=, BETWEEN, and LIKE operators. BTREE can also
be used to find NULL values. Searches against an index prefix are possible.
* HASH is only supported by the MEMORY storage engine. HASH indexes can only
be used for =, <=, and >= comparisons. It can not be used for the ORDER BY
clause. Searches against an index prefix are not possible.
* RTREE is the default for SPATIAL indexes, but if the storage engine does not
support it BTREE can be used.

Index columns names are listed between parenthesis. After each column, a
prefix length can be specified. If no length is specified, the whole column
will be indexed. ASC and DESC can be specified. Prior to MariaDB 10.8, this
was only for compatibility with other DBMSs, but had no meaning in MariaDB.
From MariaDB 10.8, individual columns in the index can now be explicitly
sorted in ascending or descending order. This can be useful for optimizing
certain ORDER BY cases (MDEV-13756, MDEV-26938, MDEV-26939, MDEV-26996). From
MariaDB 11.4.0, not only ascending, but also descending, indexes can now be
used to optimize MIN() and MAX() (MDEV-27576).

WITH PARSER Index Option
------------------------

The WITH PARSER index option only applies to FULLTEXT indexes and contains the
fulltext parser name. The fulltext parser must be an installed plugin.

COMMENT Index Option
--------------------

A comment of up to 1024 characters is permitted with the COMMENT index option.

The COMMENT index option allows you to specify a comment with user-readable
text describing what the index is for. This information is not used by the
server itself.

CLUSTERING Index Option
-----------------------

The CLUSTERING index option is only valid for tables using the TokuDB storage
engine.

IGNORED / NOT IGNORED
---------------------

MariaDB starting with 10.6.0
----------------------------
From MariaDB 10.6.0, indexes can be specified to be ignored by the optimizer.
See Ignored Indexes.

Periods
-------

period_definition:
  PERIOD FOR SYSTEM_TIME (start_column_name, end_column_name)
MariaDB supports a subset of the standard syntax for periods. At the moment
it's only used for creating System-versioned tables. Both columns must be
created, must be either of a TIMESTAMP(6) or BIGINT UNSIGNED type, and be
generated as ROW START and ROW END accordingly. See System-versioned tables
for details.

The table must also have the WITH SYSTEM VERSIONING clause.

Constraint Expressions
----------------------

Note: Before MariaDB 10.2.1, constraint expressions were accepted in the
syntax but ignored.

MariaDB 10.2.1 introduced two ways to define a constraint:

* CHECK(expression) given as part of a column definition.
* CONSTRAINT [constraint_name] CHECK (expression)

Before a row is inserted or updated, all constraints are evaluated in the
order they are defined. If any constraints fails, then the row will not be
updated. One can use most deterministic functions in a constraint, including
UDFs.

create table t1 (a int check(a>0) ,b int check (b> 0), constraint abc check
(a>b));

If you use the second format and you don't give a name to the constraint, then
the const