mysql怎么查看索引

让我告诉你一件事。
我在武汉那个电商平台工作的时候，数据库出了问题。
查索引对我来说真的很困难。
在MySQL中搜索索引时，我一般使用两种方法。
你说的两种方法我也都试过了。

第一种方法是使用SHOWINDEXFROM。
记得那年夏天，我手头有一张orders表，突然查询起来特别慢，于是我直接在MySQL客户端输入： sql SHOW INDEX FROM order;
结果出来了。
我查看了Non_unique列，发现有一个索引为1 的索引，我想，​​这个索引是不是防止发现重复数据呢？ 后来查了一下，发现是业务需求。
这个方法很好，简单直接，适合新手快速了解表结构。

其次，检查 INFORMATION_SCHEMA.STATISTICS。
我将其用于更复杂的情况。
比如我去年在上海做ERP系统的时候，有好几个表。
我需要批量检查索引状态，所以我使用了这个： sql SELECT FROM INFORMATION_SCHEMA.STATISTICS WHERE table_schema='mydb' AND table_name='orders';
结果太糟糕了，服务器几乎烧毁了。
后来发现是因为过滤条件太少，表太多。
我后来添加了 WHERE table_schema='mydb'，这使得速度更快。
该方法适用于需要精确控制查询范围的场景。

但是，我有一个陷阱。
有一次我检查了基数，发现一个索引的基数很低。
我想优化一下，但是把表删了重做，发现根本没用。
后来才知道这个Cardinality是一个估计，并不是实时更新的。
我真的不知道该笑还是该哭。
后来，每次检查这个值时，我都会先输入 ANALYZETABLE 才安心。

另外，我确实因多列索引而受了很多苦。
我记得曾经有一个索引（a，b）。
我只查看了COLUMN_NAME，没有查看Seq_in_index。
导致查询效率不高。
后来我发现顺序错了。
这是多么惨痛的教训啊。

总的来说，这两种方法都比较实用。
您可以根据情况进行选择。

MySql 三大知识点——索引、锁、事务

说白了，MySQL的索引、锁、事务是数据库性能和并发控制的三大支柱。
了解它们可以让你避免很多陷阱。

拓展一下，我们讲索引的时候最重要的B+树结构。
去年我们跑了一个千万级用户的电商项目，发现三级B+树查询（约2 000万个索引）只需要2 次磁盘I/O。
这是因为非叶子节点只存储索引，不存储数据。
还有一点就是复合索引必须遵循最左前缀原则。
例如，(“uid”,“时间”)的索引，只需搜索(“uid”)就可以使用，但只搜索(“时间”)是没有用的。
很多人不注意这一点。
还有另一个非常关键的细节。
例如，全文索引在中文场景中效果不佳，因为MySQL分词机制相对原始，除非预算足够开发Elasticsearch替代品。

一开始我以为行阻塞是稳定的，后来发现不对劲。
例如，当查询没有到达索引时，优化器会自动更新为表锁。
去年银行系统就因此被封锁了半个小时。
等等，还有一件事。
Next-KeyLock虽然可以防止幻读，但锁范围较大，在高并发写入场景下会影响性能。

关于锁机制，表锁、页锁、行锁的选择取决于公司。
去年我们改支付系统的时候，把MyISAM表锁改成InnoDB行锁，直接把并发提升了5 倍。
但请记住，Next-KeyLock 在扫描大量数据时会出现性能瓶颈。
例如，当ERP系统月底生成报表时，事务隔离级别会临时调整为RC。
说实话，挺郁闷的，因为隔离级别设置得太死板，在闪购等高并发场景下，CPU会烧坏。

最后我们来谈谈交易。
不要单击最高隔离级别。
RR级别已经可以满足9 0%的业务场景。
去年，一个 O2 O 项目强制 SERIALIZABLE，订单处理速度慢了 3 倍。
MVCC实现的核心是UndoLog和ReadView，但需要注意的是，虽然RR层防止了幻读，但读视图会随着事务的进行而不断扩大。
因此，某个社交 APP 使用 8 GB 内存。
建议监视事务日志的大小。
如果超过5 00MB，则应优化隔离级别或调整InnoDB_log_file_size。

让我们记住一个简单的陷阱：复合索引的顺序不能打乱。
例如（“状态”，“时间”）的索引。
如果你的业务需要大量数据（state=1 的数据），需要改成（“时间”，“状态”），否则索引就会变成视图。

mysql添加索引命令 mysql创建普通唯一复合索引教程

上周我的一个朋友在研究MySQL索引时发现有几种创建索引的方法：
1 常规索引，如下所示：
CREATE INDEX idx_user_name ONusers(username);
或
ALTERTABLE products ADD INDEX idx_product_category(category_id);
2 . 唯一索引，用于保证数据唯一性，例如：
CREATE UNIQUE INDEX uniq_user_email ONusers(email);
或
ALTERTABLEorders ADD UNIQUE INDEX uniq_order_number(order_number);
3 、复合索引支持多列组合查询，例如：
CREATE INDEX idx_user_name_full ONusers(last_name,first_name);
或
ALTERTABLE inventory ADD INDEX idx_product_warehouse(product_id,Warehouse_id);
4 . 复合唯一索引，提供多个列的唯一组合，例如：
CREATE UNIQUE INDEX uniq_user_product_ rating ON Product_ ratings(user_id, Product_id);
或
ALTERTABLE Student_enrollments ADD UNIQUE INDEX uniq_course_student_semester(course_id, Student_id, season_id);
如果创建索引后不再需要该索引或该索引影响性能，则可以使用 DROPINDEX 删除它。

但是请注意，索引失败的原因有很多，例如查询未命中、隐式类型转换、OR 条件使用不正确等。

要确定索引是否高效，可以使用 EXPLAIN 来分析执行计划。

复合索引中列的顺序也很重要。
例如，将最常用于等效查询的列放置在前面，将高度选择性的列放置在前面。

但是，过多的索引也会产生负面影响，例如写入性能降低和磁盘空间使用增加。

所以，最佳实践是按需创建索引，不断优化，避免过度索引。

mysql如何添加索引 mysql创建索引的三种方法详解

直接使用CREATEINDEX比较快，例如：CREATE INDEX idx_user_email ON users(email)；
ALTER TABLE也方便，改变表结构时添加，例如：ALTER TABLE products ADD INDEX idx_product_name(product_name);
建表时定义索引优化，例如：CREATE TABLEorders(order_id INT PRIMARY KEY) AUTO_INCRMENT, user_id INT, order_date DATETIME,total_amount DECIMAL(1 0,2 ), INDEX idx_user_order_date(user_id, order_date));
查询活动列并添加索引以减少 I/O 并提高速度。

在小表或经常更改的列中，应谨慎使用索引。

复合索引按常用顺序排列，例如：user_id、order_date。

太多的唯一索引、小表和低分辨率列上的索引可能会适得其反。

自己掂量一下。