mysql表索引设计问题。

Question

请各位大佬指点指点。有一个商品表，有status 0 1 2 分别代表一个商品的状态 0 审核 1 正常 2失效。
由于做的是云端商品库，供别人来采集调用的。所以基本所有的数据展示都需要status =1.还有一些小的筛选项目，我现在做的是索引如下：
所有索引基本都加了status，但是由于库是几百万几千万的库，这种效果有点差了。高并发的情况下很差。有哪位大佬有相关设计经验的能否指点一二！我现在的想法是建立历史库，把失效的放到历史库去，因为失效的基本不查询。但两张表有点麻烦，一张表能否通过合适的索引解决这个问题，请大佬指正！！

Answer 1

索引要结合数据的分布情况和具体的查询SQL来设计的，你的这些信息，还看不出你的索引设计得合理不合理。索引的作用是减少读取数据的IO，你应该根据这一点结合你具体的SQL和表数据去设计索引。我看你的索引全部都是status开头的，这并不是一种完全正确的做法，例如其中的K_SELLER索引，我估计status=1的数据应该不在少数吧，这里你调换一下索引列的位置，K_SELLER(sellid,status)，如果sellid是选择性比较高的列，那么在同样status=1 and sellid=abc的条件下，K_SELLER(sellid,status)就首先通过sellid减少了索引扫描的范围。又或者实际情况是status,sellid是更好的选择，我这里说的意思是，注意一下索引列的顺序问题。你的问题涉及太多的信息，没有亲自到实际环境，很难给出最佳的解决方案。关于建立历史库，如果你能处理好代码逻辑，减少表的数据量总是对查询有好处的。

Answer 2

商品表怎么会有几千万的数据？而且商品表上怎么会有 seller 销售员属性？我的理解你这个可能是一个销售商品的表，跟日期有比较强的关联关系，可以采用分区表的方式来处理。

Answer 3

做的淘宝客优惠券信息，定期的发布商品，优惠券过期了就吧商品弄失效，商品失效的话也就几天时间，失效的暂时没有做删除处理。所以商品加了状态筛选status

Answer 4

基本所有的数据展示都需要status =1，那还建立索引干什么？？可能效果还不如走全表扫描来得快，索引是让你快速查询到结果的。
你自己试着看一下explain语句，看下具体索引使用情况

Answer 5

楼主可以去查一下，性别字段是否需要建立索引，原理和你这个status不建立索引是一致

Answer 6

楼主可以去查一下，性别字段是否需要建立索引，原理和你这个status不建立索引是一致explain过了，用对是索引，不建立status为索引，满爆了，因为失效对商品很多，我们只需要查询没有失效对商品，但还是不够完美，看来做失效历史表是比较好的方法了