招远网站建设公司报价,app运营费用预算,租整套房做民宿的网站,长春火车站在哪个区假设你说的用户#xff0c;不是开发人员#xff0c;是终端用户#xff0c;比如saas之类的系统用户。如果对于用户是透明的#xff0c;意味着每个用户只需要看到自己的数据#xff0c;那么比较经济的处理方式是#xff0c;把用户id的哈希值作为分配的条件#xff0c;这样…假设你说的用户不是开发人员是终端用户比如saas之类的系统用户。如果对于用户是透明的意味着每个用户只需要看到自己的数据那么比较经济的处理方式是把用户id的哈希值作为分配的条件这样能够保证每个用户的数据都在同一个分配上。当用户的请求过来只需要查询这个分配就能像正常的单库单表一样的处理分页方式了。but分页也可以说两句简单的情况就是toprownumlimit这些常规方式。但是如果数据量非常大的情况下比如查询10567页的100条数据这就需要先根据where的过滤条件翻过去1056700条记录慢成狗。但是我们细想一下这么多记录用户为什么神特么的需要看这么一百万记录。。。其实就是我们自己想多了压根不可能有这种需求。怎么办要么改需求搞个热数据归档数据把24h的数据存起来其他的数据归档掉不让用户查要么不提供精确分页只让用户点击上一页下一页每次请求分页的时候不带页码只带最近的一个id比如当前页最后一个数据的id1056700点击了下一页就获取select * from tablexxx where id1056700 limit 100这样mysql就不用先去从索引数出来一百万个数据(如果是select * from tablexxx limit 1056700100)然后再去拿100个。能快的飞起。很多时候从用户角度思考问题比技术角度好得多。如果题主说的一个“用户”指的是用你这个分片中间件开发人员他非要不按用户id来分片这样就涉及到多个分片的数据聚合以后再取1056700个记录后的第100个。笨办法没有上面这个极端例子多路查询归并聚合已经不现实了。。。好办法1用canal之类的同步一个异构的读从库这个库按用户维度来分片或者不分片。好办法2把数据同步到solr或elastic-search里去做搜索。。。。。最推荐非常快。
