String columns in INFORMATION_SCHEMA tables
have a collation of utf8mb3_general_ci, which
is case-insensitive. However, for values that correspond to
objects that are represented in the file system, such as
databases and tables, searches in
INFORMATION_SCHEMA string columns can be
case-sensitive or case-insensitive, depending on the
characteristics of the underlying file system and the
lower_case_table_names system
variable setting. For example, searches may be case-sensitive if
the file system is case-sensitive. This section describes this
behavior and how to modify it if necessary.
Suppose that a query searches the
SCHEMATA.SCHEMA_NAME column for the
test database. On Linux, file systems are
case-sensitive, so comparisons of
SCHEMATA.SCHEMA_NAME with
'test' match, but comparisons with
'TEST' do not:
mysql> SELECT SCHEMA_NAME FROM INFORMATION_SCHEMA.SCHEMATA
WHERE SCHEMA_NAME = 'test';
+-------------+
| SCHEMA_NAME |
+-------------+
| test |
+-------------+
mysql> SELECT SCHEMA_NAME FROM INFORMATION_SCHEMA.SCHEMATA
WHERE SCHEMA_NAME = 'TEST';
Empty set (0.00 sec)
These results occur with the
lower_case_table_names system
variable set to 0. A
lower_case_table_names setting
of 1 or 2 causes the second query to return the same (nonempty)
result as the first query.
It is prohibited to start the server with a
lower_case_table_names
setting that is different from the setting used when the
server was initialized.
On Windows or macOS, file systems are not case-sensitive, so comparisons match both