社区
疑难问题
帖子详情
选择性低但经常出现在where条件中的字段到底要不要建索引?
Powertion
2017-04-27 06:57:27
选择性低(指字段值种类比较少,比如性别字段只有男、女)
但经常出现在where条件中的字段到底建不建索引?
疑惑
...全文
1885
7
打赏
收藏
选择性低但经常出现在where条件中的字段到底要不要建索引?
选择性低(指字段值种类比较少,比如性别字段只有男、女) 但经常出现在where条件中的字段到底建不建索引? 疑惑
复制链接
扫一扫
分享
转发到动态
举报
写回复
配置赞助广告
用AI写文章
7 条
回复
切换为时间正序
请发表友善的回复…
发表回复
打赏红包
gentleman♥️
2019-02-22
打赏
举报
回复
不太建议建,索引同样会占用硬盘空间的,数据量很大的时候,也是很恐怖的,再从另外一个方面说下 我的观点,这是因为这样的数据会分散在几乎所有的数据页中,这样的话,其实就是要把所有的数据页都加载到内存中了,这样的话,如果走索引,也是同样要加载所有的数据页到内存中,那索引这个步骤不就是多余了吗,要知道,索引中存在的数据,是在每一个个数据页中的,一个数据页会存有相应索引范围的一批数据的,而数据页是存放在硬盘上的
中国风
2017-04-28
打赏
举报
回复
不建议建,意义不大
当数据达到一定值时,都会走表扫描,是否走索引要看男/女在表占用的比例
在SQL2005时计算选择性的比例为 满足条件的行数/总行数<=0.7181,会走索引,其它会走表扫描,需要考虑特殊情况比如表数据量小<64K,SQL2012之后的版本是用列存储计算大小方式又有所不同
参照选择性就行了,有兴趣可以自己去不同版本中去测试,意义不大,掌握大概就行了
Powertion
2017-04-28
打赏
举报
回复
sqlserver文档说: 设计索引时,应考虑以下查询准则: 为经常用于查询中的谓词和联接条件的所有列创建非聚集索引。 又说: 在列中检查数据分布。通常情况下,为包含很少唯一值的列创建索引或在这样的列上执行联接将导致长时间运行的查询。 有一种说法(非官方),通过建立提高选择性的组合索引
卖水果的net
2017-04-28
打赏
举报
回复
这种情况,应该和其他的查询条件用到的字段,建立联合索引,而不是建立单列索引; 比如这样的查询比较多: select * from t where crdate > '2017-01-01' and sexid = '男' 可以建立如下索引: create index ix_t on t(crdate, sexid)
Powertion
2017-04-27
打赏
举报
回复
谢回答,我有几个字段长期固定要与另外一张表做关联,其中有两个字段的选择性相当低,基本上就是五五开了,是否也适用这种情况不用建索引?怎么总感觉关联字段都要建上索引呢
专注or全面
2017-04-27
打赏
举报
回复
1
看情况,举个例子,如果仅仅是男女,数据55开的,或者是只有1,2,3三种状态的且相对平均分布的,这种情况下索引是没用的(用不到的) 如果可以根据筛选条件过滤出来一个小的结果集,当然可以建索引 比如表中状态位有1,2,3,4,5,6,7,8,9等等,3,4,5,6,7,8,9占据了大部分数据,1,2只有少部分数据,当然可以在这个字段上建索引 对于3,4,5,6,7,8,9的查询可能不适用与索引查询,但是对于1,2就适合索引查找,那么此时建立个索引页无可厚非。
专注or全面
2017-04-27
打赏
举报
回复
看情况,举个例子,如果仅仅是男女,数据55开的,或者是只有1,2,3三种状态的,正常情况下是没用的 如果可以根据筛选条件过滤出来一个小的结果集,当然可以建索引 比如表中状态位有1,2,3,4,5,6,7,8,9等等,3,4,5,6,7,8,9占据了大部分数据,1,2只有少部分数据,当然可以在这个字段上建索引 对于3,4,5,6,7,8,9的查询可能不适用与索引查询,但是对于1,2就适合索引查找,那么此时建立个索引页无可厚非。
哪些
字段
适合
建
立
索引
?如何
建
立
索引
1、表的主键、外键必须有
索引
; 2、数据量超过300的表应该有
索引
; 3、经常与其他表进行连接的表,在连接
字段
上应该
建
立
索引
; 4、
经常出现
在Where子句
中
的
字段
,特别是大表的
字段
,应该
建
立
索引
; 5、
索引
应该
建
在
选择性
高的
字段
上; 6、
索引
应该
建
在小
字段
上,对于大的文本
字段
甚至超长
字段
,
不要
建
索引
; 7、复合
索引
的
建
立需要进行仔细分析;尽量考虑用单
字段
索引
代替: A、正确选择复合
索引
中
的主列字...
索引
加在什么
字段
会提高查询速度
索引
就像书籍的目录,只有为那些“经常被查找”的内容
建
立目录,才能真正提高查找效率。如果目录太多,反而会增加书籍的厚度(存储开销)和维护成本(写入变慢)。
索引
的目的是避免全表扫描(Full Table Scan),直接定位到目标数据行。,为那些能最大程度减少数据扫描量的
字段
建
立合适的(单列或复合)
索引
。为数据库表添加
索引
是提升查询速度最有效的手段之一,但。除了查询场景,
字段
本身的特性也决定了
索引
的效果。排序操作如果无法利用
索引
,数据库会进行昂贵的。这是最常见、最重要的
索引
场景。连接是查询
中
性能的关键点。
SQL Server
索引
到底
怎么
建
?哪些
字段
绝对不能
建
索引
?
误区真相
索引
越多越好写入性能会崩主键自动就是最优
索引
不一定只要
建
了
索引
就快用不上等于白
建
小表不需要
索引
高并发下也需要GUID 不能
建
索引
可以用非聚集
索引
索引
的本质是“用空间换时间”,但前提是:这个“时间”真的值得换。
命
中
索引
一定能提高查询速度吗?
答案是否定的,在实际项目
中
我曾踩过这个坑。在进行性能优化时,我发现一个接口的 SQL 语句没有加
索引
,EXPLAIN执行后发现是全表扫描。我对查询的
字段
添加了
索引
后,性能却没有明显提升。这是为什么呢?本文将探讨结合项目优化实例、
索引
的工作原理、影响查询性能的因素,以及在什么情况下
索引
可能不会带来预期的性能提升。
Mysql选择合适的
字段
创
建
索引
如果一个
字段
有100万行数据,但只有2个不重复值(如性别
字段
,值为“男”和“女”),那么这个
字段
的
选择性
很
低
,单独为其创
建
索引
意义不大。如果一个
字段
有100万行数据,且有90万不重复值(如用户ID
字段
),那么这个
字段
的
选择性
很高,适合创
建
索引
。:如果查询的
字段
完全包含在
索引
中
,MySQL可以直接使用
索引
而无需回表查询,这种
索引
称为覆盖
索引
。:根据实际查询的执行计划和性能瓶颈,适时调整
索引
策略,删除无用的
索引
,添加新的
索引
。:如果已经有一个复合
索引
,那么覆盖该复合
索引
的前缀列的
索引
是冗余的。
疑难问题
22,298
社区成员
121,727
社区内容
发帖
与我相关
我的任务
疑难问题
MS-SQL Server 疑难问题
复制链接
扫一扫
分享
社区描述
MS-SQL Server 疑难问题
社区管理员
加入社区
获取链接或二维码
近7日
近30日
至今
加载中
查看更多榜单
社区公告
暂无公告
试试用AI创作助手写篇文章吧
+ 用AI写文章