sql怎么查看表的索引

上周有个客人问我，在SQL里怎么查看表的索引信息？我给他详细解释了一下，不同数据库系统有不同的方法。

首先，MySQL这玩意儿，你可以通过查询information_schema.STATISTICS系统表来获取索引信息。
比如这样写：SELECT FROM information_schema.STATISTICS WHERE table_schema='your_database_name' AND table_name='your_table_name'; 这里的TABLE_SCHEMA是数据库名，TABLE_NAME是表名。
然后，MySQL还提供了一个命令SHOW INDEX FROM your_table_name;，这个命令也蛮方便的。

然后，我们来看看PostgreSQL。
在PostgreSQL里，你可以查询pg_indexes系统表，命令是这样的：SELECT FROM pg_indexes WHERE tablename='your_table_name'; 这里的tablename是表名。

Oracle也有一套自己的玩法。
你可以查询user_indexes和user_ind_columns系统表来获取索引信息，比如这样：SELECT i.index_name, i.uniqueness, c.column_name FROM user_indexes i JOIN user_ind_columns c ON i.index_name=c.index_name WHERE i.table_name='YOUR_TABLE_NAME'; 注意，这里的YOUR_TABLE_NAME要大写。

至于SQL Server，它也是通过查询系统表来获取信息的。
你可以查询sys.indexes和sys.index_columns系统表，命令可能是这样的：SELECT i.name AS index_name, i.is_unique, c.name AS column_name FROM sys.indexes i JOIN sys.index_columns ic ON i.object_id=ic.object_id AND i.index_id=ic.index_id JOIN sys.columns c ON ic.object_id=c.object_id AND ic.column_id=c.column_id WHERE OBJECT_NAME(i.object_id)='your_table_name';
除了查询系统表，你还可以用GUI工具，比如MySQL Workbench、pgAdmin、SQL Server Management Studio等，这些都是图形界面，挺直观的。
还有数据库命令，比如MySQL的SHOW INDEX，还有可能用到存储过程来获取索引信息。

反正，了解这些方法，你就能全面了解表的索引信息了，包括索引名称、唯一性、类型、包含的列以及行数等。

如何查看一条SQL语句是否用到索引

那天，我在电脑前操作PL/SQL，登录后，打开SQLwindow窗口，输入“员工信息表”，右击表名，选edit，进入indexes页面，一排排索引名字映入眼帘。
我数了数，一共1 5 个索引。
突然想到，这些索引是否真的优化了查询效率呢？

oracle中sql语句查询视图不走表索引

哎，索引这玩意儿啊，得看代价。
走索引和不走索引，哪个代价高，Oracle优化器会自己掂量。

你想看具体代价，可以用autotrace这个功能。
设置一下：
sql set autotrace on explain
然后你跑个查询，加上hint强制走某个索引：
sql SELECT /+ index(表名 索引名) / from 表名;
跑完之后，看执行计划。
autotrace会显示估计的行数、成本什么的。
走索引的路径和直接跑的路径，对比一下cost那个数字，数字小的代价就低。

说实话，优化器一般挺靠谱的，它自己选的路，大概率是成本最低的。
但你特殊时候，比如索引特别差，或者数据特别不均匀，它可能选错。
这时候你手动加hint，看看效果行不行。

就这么试一下，看看代价高不高。

mysql查看索引是否生效

说起这个MySQL的索引生效问题，我可是吃过不少亏呢。
记得那会儿，我在2 01 8 年刚接手一个项目，那数据库里索引多到数不过来，但就是不知道哪些索引有用，哪些是摆设。

一开始，我就想当然地觉得，只要创建了个索引，它就肯定能生效。
结果有一次，我写了个查询语句，想看看某个表里的数据，结果发现速度慢得要命。
我心想，这肯定是我没加索引的原因，就随便加了个索引试了试，结果还是慢。

然后我就开始怀疑，这索引是不是真的生效了？这时候，我朋友给我推荐了EXPLAIN命令。
我就按照教程，在SQL语句前面加上EXPLAIN关键字，然后执行命令。
一看结果，嘿，还真的有个索引被用了，但效率还是不高。

后来我又开始研究，发现原来这个索引虽然被用上了，但字段顺序不对，导致索引效率不高。
我就赶紧调整了字段顺序，结果查询速度瞬间就上来了。

除了EXPLAIN命令，我还发现了一个好东西，就是查询information_schema.STATISTICS表。
这个表里包含了所有索引的详细信息，我一看，原来之前创建的索引里，有些字段顺序是反的，难怪效率低。

还有，我还通过分析慢查询日志，发现了更多问题。
比如有些查询语句没有使用索引，我就针对性地优化了那些查询。

总之，这索引生效的问题，得靠多方法结合着来。
不能光靠直觉，还得学会用工具，多分析数据。
这事儿，得一步步来，不能急。
现在回想起来，当初真是踩了不少坑啊。