索引的创建和删除可以通过两种方法；一种是alter table ，另一种是create /drop index.alter table 创建索引的语法：
alter table tbl_name
|ADD {INDEX|KEY} {INDEX_NAME}
{INDEX_TYPE}(INDEX_COL_NAME,......)[INDEX_OPTION].............
|DROP{INDEX|KEY}INDEX_NAME



alter table tbl_name drop primary key;


create/drop index的语法同样很简单；
create [unique] index index_name
[index_type] on tbl_name(index_col_name...)

drop index index_name on tbl_name;



drop index index_name on tbl_name;


索引可以索引整个列的数据，也可以只索引列的开头部分的数据，如我们前面创建的表t，b列为varchar（8000），我们只索引前100个字段，如；
mysql> alter table t add key idx_b(b(100));
Query OK, 0 rows affected (0.05 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> 
目前mysql数据库存在的一个普遍的问题是，所有对于索引的添加或者删除操作，mysql数据库是先创建一张新的临时表，然后把数据导入临时表，删除原表，再把临时表重名为原来的表名，。因此对于一张大表，添加和删除索引需要很长的时间。

innodb存储引擎从版本innodb plugin开始，支持一种快速索引创建方法；当然这种方法只限制于辅助索引，对于主键的创建和删除还是需要重新创建一个表，对于辅助索引的创建，innodb存储引擎会对表加上一个S锁，。在创建的过程中，不需要重建表 ，因此速度极快。但是在创建过程中，由于上了S锁，，因此创建的过程中该表只能进行读操作，删除辅助索引操作就更简单，只需要在innodb内部视图进行更新，将辅助索引的空间标记为可用，并删除mysql内部视图上对于该表的索引定义即可；

查看表中索引的信息可以使用show index语句，如我们分析表t，之前加一个联合索引，如：

mysql> alter table t add key idx_a_b(a,c);
Query OK, 0 rows affected (0.12 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> show index from t\G;
*************************** 1. row ***************************
        Table: t
   Non_unique: 0
     Key_name: PRIMARY
 Seq_in_index: 1
  Column_name: a
    Collation: A
  Cardinality: 4
     Sub_part: NULL
       Packed: NULL
         Null: 
   Index_type: BTREE
      Comment: 
Index_comment: 
*************************** 2. row ***************************
        Table: t
   Non_unique: 1
     Key_name: idx_c
 Seq_in_index: 1
  Column_name: c
    Collation: A
  Cardinality: 4
     Sub_part: NULL
       Packed: NULL
         Null: 
   Index_type: BTREE
      Comment: 
Index_comment: 
*************************** 3. row ***************************
        Table: t
   Non_unique: 1
     Key_name: idx_b
 Seq_in_index: 1
  Column_name: b
    Collation: A
  Cardinality: 4
     Sub_part: 100
       Packed: NULL
         Null: YES
   Index_type: BTREE
      Comment: 
Index_comment: 
*************************** 4. row ***************************
        Table: t
   Non_unique: 1
     Key_name: idx_a_b
 Seq_in_index: 1
  Column_name: a
    Collation: A
  Cardinality: 4
     Sub_part: NULL
       Packed: NULL
         Null: 
   Index_type: BTREE
      Comment: 
Index_comment: 
*************************** 5. row ***************************
        Table: t
   Non_unique: 1
     Key_name: idx_a_b
 Seq_in_index: 2
  Column_name: c
    Collation: A
  Cardinality: 4
     Sub_part: NULL
       Packed: NULL
         Null: 
   Index_type: BTREE
      Comment: 
Index_comment: 
5 rows in set (0.00 sec)

ERROR: 
No query specified

mysql>

表中有3个索引；一个主键索引，A,C列上的索引，和B列上前100个字节构成的索引，以下是每列的定义：

table：索引所在表名；
non_unique:非唯一的索引，可以看到primary key 是0，因为必须是唯一的；
key_name:索引的名称，我们可以通过这个名称来DROP index；
seq_in_index:索引中该列的位置，如果看联合索引idx_a_c就是比较直观；
column_name:索引的列；
collation:列以什么方式存储索引中的，可以是A或者'NULL'。B+树索引总是A，即排序的，如果使用了heap存储引擎，并且建立了hash索引，这里会显示NULL,因为hash根据hash桶来存放索引数据，而不是对数据进行排序；
cardinality:非常关键的值，表示索引中唯一值的数目的估计值。cardinality/(表的行数)应尽可能接近1，如果非常小，那么需要考虑是否需要重建这个索引。
sub_part:是否	是列的部分索引，如果是就显示数字，如果是索引整个列，则该字段为NULL;
Packed:关键字如何被压缩，如果没有被压缩，则为NULL;
null:是否索引的列含有NULL值，可以看到idx_b这里为yes，因为我们定义了b列运行为空；
index_type:索引的类型；innodb存储引擎只支持B+树索引，所以这里显示的都是Btree;
comment:注释；

cardinality的值非常关键，优化器会根据这个值来判断是否使用这个索引，但是这个值并不是事实更新的，并非每次索引的更新，该值都会更新，因为代价大，因此这个值不太准确，只是一个大概的值；
如果需要更新索引cardinality的信息，可以使用analyze table命令；如；
mysql> analyze table t\G;
*************************** 1. row ***************************
   Table: test.t
      Op: analyze
Msg_type: status
Msg_text: OK
1 row in set (0.01 sec)

ERROR: 
No query specified

mysql> show index from t\G;
*************************** 1. row ***************************
        Table: t
   Non_unique: 0
     Key_name: PRIMARY
 Seq_in_index: 1
  Column_name: a
    Collation: A
  Cardinality: 5
     Sub_pa