alter table table_name ADD PRIMARY KEY ( seq_id ),ALGORITHM=INPLACE
增加成功的时间 视表数据量和是否有读取事务决定，风险为：
在alter的时候 ，涉及到该表的读写会阻塞。
在实际开发中使用数据库时，难免会遇到一些大表数据，对这些数据进行查询时，有时候SQL会查询得特别慢，这时候，有经验的老师傅会告诉你，你看一下哪几个字段查的多，加一个索引就好了。
那么，怎么合理地建立索引呢？这里分享一下我的一些经验，如有不妥之处，欢迎批评指正。
1、不要盲目建立索引 ， 先分析再创建
索引虽然能大幅度提升我们的查询性能，但也要知道，在你进行增删改时，索引树也要同样地进行维护。所以，索引不是越多越好，而是按需建立。最好是在一整块模块开发完成后，分析一下，去针对大多数的查询，建立联合索引。
2、使用联合索引尽量覆盖多的条件
这是说在一个慢sql里假如有五个where ，一个 order by ，那么我们的联合索引尽量覆盖到这五个查询条件，如果有必要，order by 也覆盖上 。
3、小基数字段不需要索引
这个意思是，如果一张表里某个字段的值只有那么几个，那么你针对这个字段建立的索引其实没什么意义，比如说，一个性别字段就两种结果，你建了索引，排序也没什么意思（也就是索引里把男女给分开了）
所以说，索引尽量选择基数大的数据去建立，能最大化地利用索引
4、长字符串可以使用前缀索引
我们建立索引的字段尽量选择字段类型较小的，比如一个varchar(20)和varchar(256)的，我们在20的上面建立的索引和在256上就有明显的差距（字符串那么长排序也不好排呀，唉）。
当然，如果一定是要对varchar(256)建立索引,我们可以选择里面的前20个字符放在索引树里（这里的20不绝对，选择能尽量分辨数据的最小字符字段设计），类似这样KEY index(name(20),age,job) ，索引只会对name的前20个字符进行搜索，但前缀索引无法适用于order by 和 group by。
5、对排序字段设计索引的优先级低
如果一个SQL里我们出现了范围查找，后边又跟着一个排序字段，那么我们优先给范围查找的字段设置索引，而不是优先排序。
6、如果出现慢SQL，可以设计一个只针对该条SQL的联合索引。
不过慢SQL的优化，需要一步步去进行分析，可以先用explain查看SQL语句的分析结果，再针对结果去做相应的改进。explain的东西我们下次再讲。
PS：在 select 语句之前增加 explain 关键字，MySQL 会在查询上设置一个标记，执行查询会返回执行计划的信息，而不是 执行这条SQL。
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
参数说明：
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）