千万级表，索引太大，求解

yyxxzz

Key_reads                         | 21089307   |
| Key_write_requests                | 104442899  |

这个算什么水平？ goods 表 80G,索引800多MB,server 只有2G内存，还有 java 的程序有的时候要跑

现在分配给mysql 的 key_buffer_size 只有 512MB,

导致 只有54倍 差距，goods 自建了 4个 索引，3个是复合索引，
但是 有2个复合索引，好像太大了，类似 index1 ( nick(varchar(10),total(int 11)) ) ,explain 看key_len为32
utf8 下，一个varchar 占用3个字节啊？
我把字段类型 varchar 改成 char  是不是就key_len 就12了啊，这样索引就能小不少？

yyxxzz

顶上来

cenalulu

这么大的数据量最好分表吧，先不说varchar to char的方案可不可行。
即使可行，也还是无法解决数据增长带来的问题。

varchar 和 char对于index的大小应该没有影响吧？
如果想减小体积，可以适当的减小建索引时varchar(length)的length的值

yyxxzz

这么大的数据量最好分表吧，先不说varchar to char的方案可不可行。
即使可行，也还是无法解决数据增长带来 ...
cenalulu 发表于 2010-03-08 19:00

索引中的varchar(length),现在是10，我差了一下数据库，发现最长的是11个汉字，只有一个11个汉字的
其实可能可以设置小一点8，或许也可以，但是现在的索引太大了
分表 业务逻辑上的改变应该蛮大的，现在数据表也就1000w左右

cenalulu

这个可以通过语句来决定length的大小

select count(distinct left(str_colm, length)) from table_name ；
然后除以总行数，得到比率。

length从10开始逐1减小，基本上选择性达到90%就可以了。

shushenglin

是时候分表了