如何用 mysql 按概率随机查询

可以试试 select * from products,products_description where products.master_categories_id=67 and products.products_id=products_description.products_id order by rand(10) limit 20

这是随机抽取前20条，主要是用到 order by rand()

大致流程：主库将变更写binlog日志，然后从库连接到主库之后，从库有一个IO线程，将主库的binlog日志拷贝到自己本地，写入一个中继日志 relay日志中。接着从库中有一个SQL线程会从中继日志读取binlog，然后执行binlog日志中的内容，也就是在自己本地再次执行一遍SQL，这样就可以保证自己跟主库的数据是一样的。

如果主库突然宕机，然后恰好数据还没同步到从库，那么有些数据可能在从库上是没有的，这时候从库成为了主库，那么有些数据可能就丢失了。

开启半同步复制 semi-sync ，用来解决主库数据丢失问题；

这个所谓半同步复制， semi-sync复制 ，指的就是主库写入binlog日志之后，就会将强制此时立即将数据同步到从库，从库将日志 写入自己本地的relay log之后 ，接着会 返回一个ack 给主库， 主库接收到至少一个从库的ack之后才会认为写 *** 作完成了。 如果 过程出现失败 ，那么 我们的客户端就可以进行重试了 ；

主从延迟对于读写分离的涉及影响比较大

这里有一个非常重要的一点，就是 从库同步主库数据的过程是串行化的 ，也就是说 主库上并行的 *** 作，在从库上会串行执行 。所以这就是一个非常重要的点了，由于从库从主库拷贝日志以及串行执行SQL的特点，在 高并发场景下，主库大量的写，那么从库的数据一个个的读，那么就会导致从库同步一定会比主库慢一些，是有延时的 。所以经常出现，刚写入主库的数据可能是读不到的，要过几十毫秒，甚至几百毫秒才能读取到。（主库并发写的量级越高，从库积压的同步数据越多，延迟越高）

我们可以用 show status 看看 Seconds_Behind_Master 参数，你可以看到从库复制主库的数据落后了几ms，但是这个也不是完全准确，可以看 Seconds_Behind_Master的

对于解决主从延迟，解决方案可以从以下方面考虑

数据分库表扩容-数据不均匀问题 原创

2021-12-22 22:18:13

这是王姑娘的微博

码龄10年

关注

假如前期分三个库，一个库两个表，项目火爆，数据量激增，进行扩容

增加了新的数据库表位，会导致旧的库表比新的库表数据量多，且容易出现超载情况

解决方式思想：

不同的库表位分配的概率不一样，性能好的机器和数据量少的机器提高分配几率，类似的中间件应用场景有nginx

类似这种：

Nginx常见的负载均衡策略

节点轮询（默认）

weight 权重配置

简介：weight和访问比率成正比，数字越大，分配得到的流量越高

场景：服务器性能差异大的情况使用

upstream lbs {

server 192.168.159.133:8080 weight=5

server 192.168.159.133:8081 weight=10

}

在分库表中的加权解决方式，目前想到的几种方案：

库表位可以使用对象形式，配置权重，避免数据倾斜、数据集中(思考中...)

编写算法，根据不同的，配置权重，不同的库表位配置不同的权重(思考中...)

加权配置，list重复添加出现的高频的库表位(更改速度最快)

例如：dbPrefixList.add("0")dbPrefixList.add("1")dbPrefixList.add("a")

这三个库是第一批增加的，已经到了900多万单表量。现在准备进行扩容，那么实现方式如下:

扩容库位b,c,d

/**

* 获取随机的前缀

* @return

*/

public static String getRandomDBPrefix(){

int index = random.nextInt(dbPrefixList.size())

return dbPrefixList.get(index)

}

这样在获取随机库位的时候，0,1,a获取到的概率会低点，相对进入的数据就会少些。更多数据会进入到b ,c,d中进行平衡。

---