数据库比较大有几百 G,硬盘 IO 吞吐量比较低,所以要避免全表扫描,原来业务 where 列都是加了 HASH 索引的,现在新的需求有个列是 INT(10) UNSIGNED 的数字。
先谢过。。
先谢过。。
|
tuzhenyuOct 18, 2017
1
MySql 支持 hash 索引?
|
|
opengpsOct 18, 2017
2
这个数据级别,分表分区吧
|
|
opengpsOct 18, 2017
3
我有个十亿级别数据库,sqlserver 实现的,但是,设计结构采用无主键方式,时间聚集索引
|
|
4
@tuzhenyu 对 varchar 应该可以吧,INDEX `idx_text` USING HASH(TEXT)
|
|
lujjjhOct 19, 2017 via iPhone
5
@a251922581 InnoDB 和 MyISAM 都不支持 HASH 索引。坑点在于你这么写不会报错,实际上建的却是 BTree 索引……
|
|
sagaxuOct 19, 2017 via Android
6
如果 col=222 的行很多,依然会全表扫
|
|
sunchenOct 19, 2017
7
能,不过具体效果取决于这一列的数据分布的离散情况,以及和数据主键的的分布的相关性。如果 222 的数据在 1 亿数据里分布很广,IO 依然很多
|
|
sunkukuOct 19, 2017
8
1.column 尽量不要用 int 类型
2.尽量设计多列、覆盖索引,避免二次随机寻盘 3.这个场景不适合 hash 索引,因为 hash 索引会大大增加索引空间,如果你的 hash 函数简单的话,还要处理 hash 冲突 最后一点,也是搜索效率最高的一种方法,读效率可能提升百倍。但是有大的空间损耗和写数据变慢 就是建一个冗余的表,primary key = int_column + (increased number) 。就是说让你的 int column 成为 primary key 的前缀。这样在搜索的时候,全部是顺序查找,只需要一次寻盘。 |
|
9
|