建立索引后的代价到底有多大？

前几天写的文章“MySQL 性能优化案例：覆盖索引”，介绍了使用覆盖索引优化查询的方式，受到了一个网友的批评 批评的内容为： “直接从索引放回数据很快是个常识，但是你这种单纯为了从索引返回而建索引我觉得不可取，毕竟建索引需要使用更大的空间和影响修改性能，索引是用来找数据而不是用来直接返回结果的” 当时我没有在意，因为我不认同他的说法，优化后性能的确提高了，而且我认为建立联合索引后对空间的影响、修改数据性能的影响肯定是可以接受的 后来意识到这是一个学习态度的问题，这位网友是用自己的感觉进行评论，批评得完全没有依据，而我也是用自己的感觉回应这个评论，也没有依据，这种方式是不对的，应该用数据说明问题 所以我就实际测试了一下，看建立了联合索引后，对空间、修改数据性能的影响到底有多大

测试方法

删除现有的索引，然后分别建立user_id的单列索引，和user_id及图片名称的联合索引 在这两种情况下查看索引空间占用大小，和插入相同记录条数所用的时间

测试

空间代价

单列索引 14.5M 联合索引 143M

写入性能代价

原有100万条数据，测试连续插入10条、1000条数据的时间差异 单列索引 插入10条，测试3次的结果为： 0.063、0.049、0.051 插入1000条，测试3次的结果为： 5.172、5.148、5.031 联合索引 插入10条，测试3次的结果为： 0.062、0.068、0.065 插入1000条，测试3次的结果为： 5.939、5.691、5.264

总结 在100万左右记录的情况下，索引空间大小相差了10倍，但100M的空间是可以接受的，插入性能也只是差了一点点，没有实际影响，对于我这种查询大大多于写入的场景完全可以接受 这个小实验有点无聊，重点是学习态度，思考问题的方式

以后当我对别人的结论有质疑，或者面对别人的质疑时，不会只凭感觉，会主动寻找依据