mysql怎么查看索引

嗯...在 MySQL 中查看索引有两种主要方法。

第一个是使用SHOW INDEX命令。
如果您考虑一下...语法是... SHOW INDEX FROM table_name;例如...要查看 Customers 表，请键入...SHOW INDEX FROM Customers；这将为您提供几个结果...查看表名称...表...这意味着索引位于哪个表上。
然后 Non_unique...这是 0 表示唯一索引...1 表示不唯一...即允许重复。
Key_name...是称为索引的名称。
主键的默认值为 PRIMARY。
Seq_in_index...这个比较重要...看吧，如果你建立一个组合索引...比如你按last_name，然后first_name...那么Seq_in_index会告诉你last_name是first...first_name是second...顺序是什么？ Column_name... 是索引列的名称。
数据排序...如何对列进行排序。
例如，A 按升序排列。
NULL 表示不对齐。
基数...这非常重要...它是对索引中有多少个唯一值的估计...优化器在选择索引时依赖于此。
Sub_part...如果存在...意味着仅对列的前几个字符（例如前 1 0 个字符）建立索引。

另一件事...是检查 INFORMATION_SCHEMA.STATISTICS 表。
语法为 SELECT FROM INFORMATION_SCHEMA.STATISTICS WHERE table_schema='database_name' AND table_name='table_name';例如...要查看 mydb 库中的 customer 表索引...键入以下查询...SELECT FROM INFORMATION_SCHEMA.STATISTICS WHERE table_schema='mydb' AND table_name='customers';。
显示的列...TABLE_SCHEMA...是数据库名称。
TABLE_NAME...表名称。
INDEX_NAME...索引名称。
NON_UNIQUE...相当于SHOW INDEX 中的Non_unique。
0 是唯一的，1 不是唯一的。
CARDINALITY... 与 SHOW INDEX... 中的 Cardinality 相同，唯一值的估计数量。
COLUMN_NAME...索引列的名称。

需要注意的一点...其中之一是...权限...您必须拥有权限...要进行检查，您必须对该表具有 SELECT 权限。
另外一个是...基数是一个统计值...它可能不是实时更新的...如果你认为它不准确...你可以使用ANALYZE TABLE命令刷新这个统计值...比如ANALYZE TABLE客户。
另外...如果您正在构建多列索引...您应该查看 Seq_in_index...这会告诉您列的顺序...或者您应该多次检查...并弄清楚这个组合索引是如何排列的。
列顺序。

如果你想知道所有表的索引...你可以省略WHERE条件...或者先检查INFORMATION_SCHEMA.TABLES以获取所有表名...然后动态生成查询...并包含所有表名。

哦...还有一件事...如果您使用 EXLAIN 来分析查询...例如 EXPLAIN SELECT FROM customer WHERE last_name='Smith';...结果中会有一个键列...该键将告诉您在实际执行过程中使用了哪个索引。

简而言之...这两种方法...可以帮助您了解MySQL表的索引结构...这将帮助您优化查询性能。

mysql如何查看表的索引列表 mysql如何查看表的索引类型分类

嘿，让我告诉你我在做这件事时遇到的陷阱。

当时，我刚刚接管一个电子商务网站，服务器就停止工作了。
当我检查后台时，我注意到由于查询日志中有大量的EXPLAIN，导致索引丢失。
我顿时吓坏了，立马打开客户端看表索引。

第一种方法SHOW INDEX FROM是最简单粗暴的。

输入以下内容：
sql 查看订单索引；
出现了各种结果。
我一看，发现这个表里居然有2 0多个索引，而且索引的名字都是随机的。
随便一看，有idx_user_id，Non_unique为0表示是唯一索引，Key_name为user_id。
嘿，我需要添加这个。
用户表应通过用户 ID 进行检查。

第二种方法information_schema.STATISTICS更加灵活。

当时我正在批量导入数据，想看看是哪个表索引出了问题。
直接使用这个：
sql 选择表名称、索引名称、索引类型、基数 FROM 信息模式.STATISTICS WHERE TABLE_SCHEMA = '电子商务' 且基数 < 1> 结果是不言自明的。
我发现有些表的索引基数特别低。
这意味着重复值很多，索引没有用。
例如，我的 idx_status 全部为“1 ”和“0”。
我应该检查什么？我冒险把它删除了。

当时，我在索引分类的这方面遇到了困难。

我有一个产品表。
我想添加全文索引 FULLTEXT INDEX 并检查产品描述。
结果？根本不要引用该索引。
我检查了一下，发现全文索引仅在InnoDB引擎中可用，而我的表来自MyISAM。
实在是让人哭笑不得。

说到索引类型，我遇到了BTREE和HASH的陷阱。

我有一个序列表，主键是一个自动递增的ID。
您需要在 order_status 上创建 HASH 索引。
结果？检查订单状态非常慢。
后来才知道HASH索引只能精确匹配。
检查 order_status = 'processing' 是可以的，但如果你想检查 order_status LIKE 'processing%' 你就是个白痴，它肯定不会被索引。

复合索引是最麻烦的。

我有一个表，它是用户订单表。
添加了复合索引 idx_user_id_order_date。
因此，企业需要检查 user_id = 1 00 AND order_date > '2 02 3 -01 -01 '。
起初我以为复合索引肯定会消失，但运行 EXPLAIN 后我发现它还没有消失。
为什么？由于我没有按顺序执行它们，所以我完全忘记了最左前缀原则。
只需直接将其更改为 idx_user_id_order_date 即可。

不要忘记清理索引以维护此空间。

当时，我们的表有太多索引，服务器宕机了。
我检查了一下，发现了数百个冗余索引。
这些都是开发时盲目添加的。
只需使用 ALTER TABLE DROP INDEX 将它们一一删除，您的服务器将立即变得更快。
因此，定期清理索引非常重要。

此外，检查外键关系也很麻烦。

我有一个表依赖于另一个表，但我忘记添加外键。
结果，数据插入失败。
直接使用这个：
sql 选择表名称、COLUMN_NAME、REFERENCED_TABLE_NAME、REFERENCED_COLUMN_NAME FROM 信息 schema.KEY_COLUMN_USAGE WHERE TABLE_SCHEMA = '电子商务';
检查的时候发现少了外键约束，于是赶紧添加了。

这意味着您需要将类似索引的内容与实际场景结合起来。

当时我有一个表，它是包含数十亿数据的日志表。
全文索引不可用并且被卡住。
然后我通过使用 BTREE 和 INDEX 并使用 WHERE 条件进行过滤解决了该问题。

如您所知，索引越多越好。
取决于数据量、查询模式和存储引擎。
低基数、HASH 索引的错误使用以及无序复合索引都是我遇到过的陷阱。

希望这些个人经历​​对您有用。
别像我一样胡闹。