前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >建立索引后的代价到底有多大?

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

作者头像
dys
发布2018-04-03 16:40:02
1.5K0
发布2018-04-03 16:40:02
举报
文章被收录于专栏:性能与架构

前几天写的文章“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的空间是可以接受的,插入性能也只是差了一点点,没有实际影响,对于我这种查询大大多于写入的场景完全可以接受 这个小实验有点无聊,重点是学习态度,思考问题的方式

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

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2016-02-26,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 JAVA高性能架构 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
云数据库 SQL Server
腾讯云数据库 SQL Server (TencentDB for SQL Server)是业界最常用的商用数据库之一,对基于 Windows 架构的应用程序具有完美的支持。TencentDB for SQL Server 拥有微软正版授权,可持续为用户提供最新的功能,避免未授权使用软件的风险。具有即开即用、稳定可靠、安全运行、弹性扩缩等特点。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档