实现语音社交源码接口性能优化，从索引入手

说起语音社交源码的接口性能优化大家第一个想到的可能就是优化索引。没错，优化索引的成本是最小的一种方式。

通过查看线上日志或者监控报告，查到语音社交源码某个接口用到的某条sql语句耗时比较长。

这时你可能会有下面这些疑问：

• 语音社交源码中的该sql语句加索引了没？
• 加的索引生效了没？
• mysql选错索引了没？

一、没加索引

sql语句中where条件的关键字段，或者order by后面的排序字段，忘了加索引，这个问题在语音社交源码中很常见。

语音社交源码刚开始发展的时候，由于表中的数据量小，加不加索引sql查询性能差别不大。

后来，随着业务的发展，表中数据量越来越多，就不得不加索引了。

可以通过命令：

show index from `order`;

能单独查看某张表的索引情况。

也可以通过命令：

show create table `order`;

查看整张表的建表语句，里面同样会显示索引情况。

通过ALTER TABLE命令可以添加索引：

ALTER TABLE `order` ADD INDEX idx_name (name);

也可以通过CREATE INDEX命令添加索引：

CREATE INDEX idx_name ON `order` (name);

不过这里有一个需要注意的地方是：想通过命令修改索引，是不行的。

目前在mysql中如果想要修改索引，只能先删除索引，再重新添加新的。

删除索引可以用DROP INDEX命令：

ALTER TABLE `order` DROP INDEX idx_name;

用DROP INDEX命令也行：

DROP INDEX idx_name ON `order`;

二、 索引没生效

通过上面的命令我们已经能够确认索引是有的，但它生效了没？此时你内心或许会冒出这样一个疑问。

那么，如何查看语音社交源码中的索引有没有生效呢？

答：可以使用explain命令，查看mysql的执行计划，它会显示索引的使用情况。

例如：

explain select * from `order` where code='002';

结果：

通过这几列可以判断语音社交源码中索引使用情况，执行计划包含列的含义如下图所示：

说实话，sql语句没有走索引，排除没有建索引之外，最大的可能性是索引失效了。

下面说说索引失效的常见原因：

如果不是上面的这些原因，则需要再进一步排查一下其他原因。

三、 选错索引

此外，你有没有遇到过这样一种情况：明明是同一条sql，只有入参不同而已。有的时候走的索引a，有的时候却走的索引b？

没错，有时候语音社交源码中的mysql会选错索引。

必要时可以使用force index来强制查询sql走某个索引。