数据库索引怎么看？索引创建原则与查询优化技巧有哪些？

数据库索引是数据库管理系统中用于提高查询效率的重要数据结构,其核心思想通过创建特定的数据结构（如B+树、哈希表等）来加速数据检索，减少磁盘I/O操作，要深入了解数据库索引的查看方法、原理及优化策略，需从索引的基本概念、查看方式、使用场景及注意事项等多个维度展开分析。

数据库索引的基本原理

索引的本质是一种数据结构,常见的类型包括B+树索引、哈希索引、全文索引等，以最常用的B+树索引为例，其结构类似于多路平衡树，所有数据记录都存储在叶子节点，且叶子节点通过指针相连形成有序链表，当执行查询时，数据库可通过索引的有序性快速定位数据，避免全表扫描，对于SELECT * FROM users WHERE id = 100;这样的查询，若id列建立了索引，数据库可直接通过B+树定位到id=100的记录，而无需逐行扫描整个users表。

如何查看数据库索引

不同数据库系统（如MySQL、PostgreSQL、Oracle等）提供了不同的命令和工具来查看索引信息，以下是主流数据库的查看方法：

MySQL

• 
  在指定表后执行SHOW INDEX FROM 表名;，可查看该表的所有索引信息，包括索引名、列名、索引类型（是否唯一）、排序规则等。

  SHOW INDEX FROM users;

  返回结果包含以下关键字段：

  • Key_name：索引名称
  • Column_name：索引列名
  • Non_unique：是否唯一（0为唯一，1为非唯一）
  • Seq_in_index：索引中列的序号（联合索引时显示列的顺序）

• 
  通过系统表STATISTICS或KEY_COLUMN_USAGE可获取更详细的索引元数据：

  

  SELECT * FROM information_schema.STATISTICS WHERE table_name = 'users';

PostgreSQL

• 
  在psql命令行工具中，执行d 表名可显示表的索引信息，包括索引名称、索引表达式、是否唯一等。

  d users;

  输出中会以"索引名"列名 (类型)的格式展示索引，例如"idx_users_email" email varchar(255) UNIQUE。

• 查询系统目录pg_indexes
  通过SQL查询系统表获取索引详情：

  SELECT indexname, indexdef FROM pg_indexes WHERE tablename = 'users';

Oracle

• 使用USER_INDEXES和USER_IND_COLUMNS视图
  查询当前用户的索引信息：

  SELECT index_name, index_type, uniqueness FROM user_indexes WHERE table_name = 'USERS';
  SELECT index_name, column_name FROM user_ind_columns WHERE table_name = 'USERS';

  联合查询可获取索引名、类型、唯一性及包含的列。

SQL Server

• 
  执行EXEC sp_helpindex '表名';可查看表的索引信息，包括索引名称、键列、包含列、索引类型等。
• 查询系统视图sys.indexes

  SELECT name, type_desc, is_unique FROM sys.indexes WHERE object_id = OBJECT_ID('users');

索引的查看结果分析

以MySQL的SHOW INDEX为例，返回结果可能如下表所示：

Key_name	Column_name	Non_unique	Seq_in_index	Index_type
PRIMARY	id	0	1	BTREE
idx_username	username	1	1	BTREE
idx_email	email	0	1	BTREE

• Key_name：索引名称，主键索引通常显示为PRIMARY。
• Non_unique：0表示唯一索引（如主键、唯一约束），1表示非唯一索引。
• Index_type：索引类型，BTREE为B+树索引（MySQL默认），HASH为哈希索引（仅用于精确匹配）。

通过分析这些信息,可判断索引是否合理：联合索引（Seq_in_index > 1）需注意列顺序是否符合查询需求，唯一索引是否用于约束业务数据等。

索引的优化与注意事项

1. 索引的适用场景：

   • 适合用于WHERE、JOIN、ORDER BY等频繁查询的列。
   • 适合高基数列（如用户ID、邮箱），低基数列（如性别、状态）建索引效果可能不佳。

2. 索引的局限性：

   • 索引会占用额外存储空间,降低写操作（INSERT/UPDATE/DELETE）速度，因为每次写数据需维护索引结构。
   • 不适合小表或频繁更新的列,例如统计表、日志表的全字段更新场景。

3. 索引失效的情况：

   • 对索引列使用函数（如WHERE SUBSTR(name, 1, 3) = 'abc'）、表达式或类型转换（如WHERE id = '100'，id为INT类型）。
   • 使用LIKE '%abc'（前导模糊查询）会导致索引失效。
   • 联合索引未遵循最左前缀原则（如索引为(a, b, c)，查询条件仅包含b或c）。

相关问答FAQs

Q1: 如何判断索引是否被实际使用？
A1: 可通过数据库的执行计划（如MySQL的EXPLAIN、PostgreSQL的EXPLAIN ANALYZE）查看查询是否命中索引，在MySQL中执行EXPLAIN SELECT * FROM users WHERE id = 100;，若type列显示为const（主键/唯一索引匹配）或ref（普通索引匹配），且key列显示使用的索引名，则说明索引生效；若type为ALL，则表示全表扫描，索引未使用。

Q2: 索引越多越好吗？如何平衡索引数量与性能？
A2: 索引并非越多越好，过多的索引会增加写操作的开销和存储空间，同时可能导致查询优化器选择错误的索引（如索引选择性低时），建议根据业务场景选择性建索引：优先为高频查询的列、作为连接条件的列建索引；定期通过慢查询日志分析未使用的索引，考虑删除；对联合索引，需测试列顺序是否符合最左前缀原则，避免冗余索引。