Mysql大表加索引

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

参数说明：

100万数据加索引要1分钟。索引跟类型关系很大，一般定长字段比变长字段简单，IO消耗小，时间节省，复合索引变长越多就越复杂，其次就是一表多索引，这种情况会衍生各种存储索引结构，就更费时间了。表的数据页，文件数量，每页槽位都会影响时间。

100万数据加索引注意事项

百万数据量以上时mysql不带索引查询会非常慢。利用索引和复合索引来逐一提升查询效率。复合索引的顺序必须与查询的顺序一致，即查询时state在前和createtime在后，创建复合索引时也要保持同样的顺序，否则复合索引失效。还有百分号在左也会导致索引失效，无论是单索引还是复合索引。

---