mysql 加索引需要多长时间？

32核心，30多G 内存，一千万的条目在时间上建立非聚集索引，用了 7 分钟。

一亿的话，我这估计要大于70分钟。

聚集索引时间更长。 这个需要索引排序，建立分支索引复合B树。

一般海量数据不如新建立表，建立好索引，然后逐批导入数据。

差劲点的机器，一亿数据建立索引基本就是死机或是僵尸状态。

只能慢慢的等了，一天都不行，就上边那方法。

索引跟类型关系很大，一般定长字段比变长字段简单，IO消耗小，时间节省，复合索引变长越多就越复杂，其次就是 一表多索引，这种情况 会衍生各种存储索引结构，就更费时间了。

表有多少数据页，多少文件，每页多少槽位都会影响时间。

select (*) from tb_name where create_time >xxx

最终得知是因为这个表数据行数已经超过 一千万了，然后create_time字段又没有索引 。

那解决办法肯定是加索引喽。

但是这个表是一直在线上运行，很重要和业务部分。如果给千万级的大表在线加索引 ，肯定会卡死。

然后就搜罗了一大筐解决方案，比如 在线无锁加索引使用

ALTER TABLE tbl_name ADD PRIMARY (column), ALGORITHM=INPLACE, LOCK=NONE

后来才发现，这个特性是 Mysql 5.6 以后才支持，然而我们的mysql用的是5.5版本

最后在 《高性能Mysql》一书中看到，可在通过 “影子拷贝”来解决，

就是 先创建一张和源表无关的新表，然后通过重命名和删表 *** 作交换两张表；

当给新表加完索引后，最上面那条查询直接就是0.0002s

场景：在给一张有几万条记录的表添加索引时，进度非常慢，导致其它查询无法进行

处理方式：

使用Navicat的命令行模式，执行以下命令：

show processlist

这时会看到有哪些线程正在执行，也可以查看锁表的线程。你会发现alter table * add key ****那个线程状态是Waiting for table metadata lock，后面有个这个表的所有 *** 作都是这个状态，很明显是这条加索引的语句把表给锁了。

查看线程ID，执行

kill 线程ID

这样被锁住的表就能立即被使用了。

由此得出一个结论，当一张表数据量很大时，不要轻易添加索引，会导致表被锁死！如果非要添加，那么应该先把数据表进行备份，然后进行空表添加索引。

只能通过ALTER TABLE不能create index

参数说明：

---